On Tue 2015-05-19 15:55:34 -0400, Daniel Roesler wrote: > On Tue, May 19, 2015 at 4:04 AM, ma...@wk3.org <ma...@wk3.org> 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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel