Re: [Sks-devel] Proposal: Start verifying self-signatures

[Daniel Kahn Gillmor]

On Tue 2015-05-19 15:55:34 -0400, Daniel Roesler wrote:
> On Tue, May 19, 2015 at 4:04 AM, address@hidden <address@hidden> wrote:
>> But there was also the question on how to deal with the situation on
>> a more conceptual level and I don't know what this would entail in a
>> technical sense,
>
> Here's a proposed phased technical rollout of verifying self signatures.

For the sake of cleanliness, I do like your proposal about filtering
"normal" (non-gossip) uploads and masking cryptographically-invalid
packets from the user-facing download and/or display [0].  However, I note
that these cleanliness features do nothing to defend against the abuse
of the keyserver network, or to defend a trusting user from a malicious
keyserver.  They just provide cleanliness in the case where everyone is
playing together nicely (maybe that's enough to push the approach
forward!).

But the tough core of what you're proposing here is the phasing in of a
new set of filters for members of the SKS pool.

FWIW, I agree that a new set of filters is probably warranted.  You can see a
suggestion i made for an additional filter here that i think is at least
as important as verifying self-signatures:

 https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20

You'll note there that it was deferred because apparently no one knows
how to update the filter code cleanly :(

Even if we did have a better understanding of the filter code, the
difficulty with phasing in filters like this (as you've noticed in your
description) is that either the whole pool opts in, or the filter
doesn't work.  Peers with different filtersets cannot gossip with each
other, aiui.

So if we're going to introduce new filters, we are going to cause a
major disruption with the existing SKS network.  While such a disruption
may be warranted, it is probably not something we want to do twice, so
we should roll all the desired filter changes into one massive
disruption.

Alternately, we could start up a new keyserver pool in parallel with the
existing one, but make sure the new pool only allows members with the
proper filterset.  There would then need to be some sort of modified
gossip protocol that can bridge the old pool with the new pool.


> This would close the hole where a troll could bloat the size the
> database for keyserver operators.

Except that it wouldn't.  As others have mentioned, there are still many
other ways that a troll could bloat the database, even after your 2017
deadline. :(


So the questions i have for a proposal like this:

 * what is the set of filters we ultimately want?

 * for each filter, is the goal just cleanliness, or does it provide
   some sort of strong protection for someone in the SKS/OpenPGP
   ecosystem?

 * If it provides strong protection, who does it provide it for, and
   against what attack?

 * if it provides strong protection, and some players in the ecosystem
   are malicious, does the promised protection still hold?



Alternately, a solid answer to the following question would help us to
make these sorts of decisions in a more fine-grained way over time:

 * how do we update the SKS gossip protocol in such a way that peers
   with different filtersets can interact cleanly?

      --dkg

[0] i note that "cryptographically-invalid packets" is actually not
    straightforward to determine with OpenPGP v4.  what we think of as a
    self-signature packet is actually a signature packet that happens to
    be made by the primary key.  The only indication of which key made
    the packet is the Issuer subpacket, which contains nothing but the
    64-bit keyid of signing key.  Since we know that there are
    collisions in the 64-bit keyid space, knowledge that a given
    signature packet does not validate actually might mean we just don't
    have the right signing key available -- indeed, the "self-sig" might
    not be a self-sig after all.

    I suspect we could punt on this concern, by saying "an updated SKS
    keyserver network won't accept any certifications from key X to key
    Y if they share a 64-bit keyID", but there might be several
    heuristics like this that we'd need to introduce just to satisfy
    your "self-sigs must validate" filte.

signature.asc
Description: PGP signature