Why hashed User IDs is not the solution to User ID enumeration

[Robert J. Hansen]

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 <admin at alice.org> From: Bob's Administrator
> <admin at 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.