auto refresh-keys

[Hauke Laging]

Hello,

Am Freitag 18 Juni 2010 02:10:22 schrieb MFPA:

> I don't know how common or uncommon it might be. I just know that, of
> the keys in my keyring of about 400 keys, I have noticed more
> deviations away from my default keyserver to key.asc files than to
> alternate keyservers.

but this is about the share of file URLs in the keyring not the number of file 
URLs against the number of alternative key servers.

Another point: With a good auto refresh infrastructure less people might feel 
the need to use such a file URL.


> > If your keyservers don't support TLS (I have no idea
> > whether the important ones use it) then you are open to
> > a MitM attack when checking them. If the response is
> > signed then you are not (if you are sure about the
> > signing key :-) ).
> 
> OK, up to a point. But the web of trust should thwart this MitM
> attack. Or am I missing something?

You are missing the kind of attack. The WoT prevents you from being attacked 
by modified keys. It does not prevent you from being "attacked" by non-updated 
keys. The attacker can send you the file you already have. This is more a DoS 
attack with security implications for revoked and added keys and 
organizational implications if you need more signatures to verify a key.


> A user with several systems could use common keyrings. Or his own
> local keyserver. Or just export all keys from the keyring he has just
> updated and import them into each of his other keyrings.

Yes but it seems to me that none of that is equally convenient to simply 
passing the timestamp file to the other systems. OK, I admit that I have just 
considered the case that no keys have to be updated. It makes sense to create 
a singed bulk download option, too. First you request the timestamps, next you 
request all keys you need to update. That would allow to avoid server accesses 
completely by simply passing both signed files (timestamp list and key 
collection).


> >  Several users might
> > even combine their ID wishlist so that only one of them
> > has to ask the keyserver.
> 
> Possibly in a corporate or group setting, where one person could
> refresh the keyring and push the update to his colleagues?

Yes. That would be kind of a caching proxy service. Privacy protection could 
be reached by taking "secret" IDs off the list for the "proxy guy". Unrevealed 
IDs would be checked directly. If gpg was to be extended by an option to 
create an ID list I would suggest the feature to mark keys as not to be 
revealed by such update lists.


> I guess there is a risk if the change was a revocation because the key
> has been compromised, and it only reached the bad guy but not the real
> keyserver, and you had only tried to send it to that one server.

Sending to several keyservers does not help if the MitM attack point is on 
your side.



> > Look at it the other way round: The more keys there are
> > in the keyring the more bandwith is saved. I am
> > convinced that users with large keyrings have enough
> > local storage for that...
> 
> And if they are using a mobile device with limited storage they
> probably aren't using a large keyring?

How large is your keyring file? I assume that for ten checked keyservers the 
file for storing the last timestamp for each key and keyserver would not even 
have the size of the keyring.

And if there are only 40 KiB of space left on the device then IMHO you simply 
have to face the truth: That the wrong device it used for the application 
GnuPG.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100618/4ad02227/attachment.pgp>