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

[John Clizbe]

Jerome Baum wrote:
> On 2012-01-28 06:14, Robert J. Hansen 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)?
> 
> (So in this scenario I'm assuming the key owner adds e.g. a
> self-signature with a special notation listing the packets that they
> want to be published on the keyserver.)
> 
> Or was this more about "old" keys -- that don't have the special
> self-signature -- dropping out of the network? How about making the
> publish control optional -- if the self-sig doesn't say "I want to
> control my published stuff" then just publish all packets?

You've just outlined the problem. The present behavior of all keyservers is to
merge packets. If the no-modify behavior is introduced, that server is going to
drop or refuse packets. How do you reconcile keys when you have two legal
behaviors in place within the network? Differing copies of a key is _NOT_ an option.

The thing that makes SKS so fast is its reconciliation scheme which relies on
logically identical or near identical copies of the keystore. If two variant
copies of the same key are allowed to exist, they will endlessly be exchanged
between servers, thus crippling the reconciliation process as more no-modify
keys are sent to the keyservers.

It has nothing to do with what is or isn't published. You ask for key
0xdecafbad, you get all of the key. What it has to do with is _what_ gets stored
and how those decisions are made. Differing algorithms equate to differing keys.

I tagged SKS 1.1.2 at the end of September. Currently there are four versions of
SKS running in the network: 1.0.10, 1.1.0, 1.1.1, 1.1.2. I think the 1.0.9
servers finally upgraded.  Getting all servers on the same release would in
itself be a large undertaking and would be required for a no-modify scheme to work.

I don't see a way that a rolling-upgrade to a no-modify supporting version could
be accomplished without breaking things in the process. The only way I can
envision doing this to to form a completely new network and let servers migrate
into it as they upgrade to the no-modify supporting version.  In a way, that's
also undesirable as it divides the widely distributed network in two.

There's really no simple way to retrofit no-modify behavior into an existing
keyserver network.


-- 
John P. Clizbe                      Inet:John ( a ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

                   Cowboy Haiku -- Reflections on Rodeo
So many Cowboys. / Round Wrangler butts drive me nuts. / Never enough rope.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120128/4178d592/attachment.pgp>