On 1/28/2012 12:48 AM, Jerome Baum wrote:
>> It isn't just that no one's written the code: it's there's no
>> community consensus to deploy such code, even if it were written.
>> It would be a pretty major flag day. After all, if one keyserver
>> enforces it and others don't, then that's going to create a pretty
>> obvious syncing problem.
>
> What syncing problem is that? Wouldn't the crypto-supporting
> keyserver simply sync out (provide to other keyservers) it's
> published packets and sync in everything (yet drop packets without a
> "publish" signature)?
We have two scenarios: either the no-modify keyserver retains all the
now-ignored signatures or else it doesn't. For sake of argument, let's
call the no-modify keyserver 'Alice', and the old keyserver 'Bob'.
Scenario 1: Alice throws away the now-ignored data.
Bob: Hi, Alice! Let's sync.
Alice: Hi, Bob! I see we have different records for 3,731 certs.
Bob: Here you go, Alice!
Alice: Thanks. [reads 3,731 certs, strips off now-verboten UIDs]
... five minutes later ...
Bob: Hi, Alice! Let's sync.
Alice: Hi, Bob! I see we have different records for 3,731 certs.
Bob: Here you go, Alice!
Alice: Thanks. [reads 3,731 certs, strips off now-verboten UIDs]
[24 hours and a few million redundant cert exchanges later]
> To: Alice's Administrator <ad...@alice.org> From: Bob's Administrator
> <ad...@bob.org> Subject: FIX YOUR BROKEN KEYSERVER ALREADY
>
> I've removed you from my peer lists until you can fix your
> installation.
Scenario 2: Alice retains the now-ignored data, serving to GnuPG
clients the version that honors no-modify, and serving to
other keyservers the full version
Bob: Hi, Alice! Let's sync.
Alice: Are you a GnuPG client or a keyserver?
Bob: [glazed look in his eye] I'm sorry, Alice, that's not
a request I understand. I'm an SKS keyserver, version 1.1.2.
Could you repeat?
Scenario 2a: As with 2, but now we have an SKS 1.1.3 that somehow
identifies itself as being a keyserver and not a GnuPG client.
Bob: Hi, Alice! Let's sync.
Alice: Are you a GnuPG client or a keyserver?
Bob: Why, a keyserver, of course.
Alice: Cool! Here, have these certs, complete with the data that
you shouldn't distribute outside of the keyserver network.
Remember, that stuff is for us to use for ease of sync, not
to be given to end-users under any circumstances, or else
they'll wonder what the point is in the no-modify flag!
Bob: Uh. Sure. Whatever you say, Alice. (Bob, being a 1.1.3
SKS server, has no idea what Alice is talking about: he
doesn't support no-modify.)
Scenario 2b: As with 2, but now imagine you have a malicious host,
Mallory, who wants to get full certificates.
Mallory: Hi, Alice! Let's sync.
Alice: Are you a GnuPG client or a keyserver?
Mallory: [twirls Snidely Whiplash moustache] A keyserver!
Alice: Here, have all these certs, complete with the UIDs that
shouldn't be distributed outside the keyserver network!
... Short version: for no-modify to work with the existing keyserver
network, everyone would have to make the cutover or else the network
would drown in sync messages. There's a real possibility that if just a
few hosts didn't make the cutover that the keyserver network could go
down, DDoSing itself into absolute oblivion as it desperately tried to
sync keys infinitely.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
