David Shaw wrote: > On Jun 14, 2012, at 4:34 PM, Robert J. Hansen wrote: > >>> 1) If the keyserver (of whatever type) isn't reachable... >> >> As you say, easy to solve: agreed. >> >>> 2) Concern that enough people turning this feature on would add >>> significant load to the keyserver network...
I don't think the network as a whole would be adversely impacted. Where the slamming would occur is well-known servers that "everybody" uses, e.g., pgp.mit.edu. >> An open question and one we'd need to address: agreed. >> >>> 3) It leaks information more than auto-key-retrieve or auto-key-locate >>> does. See logging/leak discussion below. >> I'm not entirely sure this is a problem. If you're concerned about the >> keyserver operator knowing that you're acquiring certificates, why would >> you use that keyserver? Why not use a different keyserver instead? If >> there were a single centralized keyserver, or a keyserver hierarchy where >> individual nodes took marching orders from those above them, this would >> be much more of a problem -- but here, the decentralized nature of the >> keyserver network seems to work in our favor. Which is why we suggest folks us one of the sks-keyservers.net pools. There are multiple pools to choose from besides the basic pool.sks-keyservers.net. See http://www.sks-keyservers.net/overview-of-pools.php for a description of the various pools. > 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 > Werner also showed a way to configure AKL to always fetch a key from a > keyserver, which can be done with today's code. You remember where that was? Sounds interesting, and I have plenty of keyservers here at home to choose from. -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users