dshaw at jabberwocky.com
Sat Jun 16 23:32:36 CEST 2012
On Jun 15, 2012, at 12:33 PM, John Clizbe wrote:
>> It's a similar problem in type as auto-key-retrieve or auto-key-locate, but
>> it's a different problem in degree: both AKR and AKL fire only as needed
>> (either when a key is needed for sig verification, or when a key is needed
>> to encrypt to). That's a single fetch for the life of the key (you might
>> fetch it more via other means, but AKR and AKL (barring special
>> configuration) will never fetch a key you already have). Fetching the key
>> on each usage means it leaks each time you use the key. Plus remember that
>> by default, GPG honors keyserver URLs on the key, which if combined with
>> this new feature enables IP-address tracking of a person encrypting to a
>> particular key (it's the same web-bug trick as AKR, but with encryption).
> Another good reason to use one of the round-robin pool addresses rather than a
> single keyserver. I have to go back and check but I believe that that level
> of logging is a 5. SKS defaults to 4 and most operators never change it. Only
> we crazy developers go for logging that detailed
Yes, I understand that spreading out keyserver requests can help avoid this sort of tracking, but remember that the keyserver URL feature allows the keyholder to bypass the keyserver chosen by the user, and send the requests anywhere they like. I don't care how the keyserver round-robins are run if I can get a target GPG to not use them.
To really combat tracking, you need to route your keyserver requests through TOR or something similar.
More information about the Gnupg-users