RFE: --update-before-use

[John Clizbe]

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-keys at 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"