On Mon, 23 Mar 2009 17:25, [email protected] said: > Actually, i do run one of the public keyservers. Even if i didn't, > there are some keyservers run by organizations which i believe have my > interests in mind more than others. For example, i might prefer an > organization who commits to the following behaviors:
Okay, so a reason for using TLS would be a private or company keyserver. I can see that an the wish t use use TLS instead of a VPN. > I agree that it should be impossible for a malicious keyserver to forge > new signatures. However, a malicious keyserver could non-detectably > strip signatures (e.g. removing revocation certificates, or certificates Which happened in the past oft enough due to buggy keyserver codes and we can't be 100 percent sure that this won't occur in the future again. > But not all keyservers have enough guaranteed traffic, and not everyone > wants to (or can afford to) saturate the network with filler queries. Anonymity comes at a price. > Furthermore, tor introduces an additional communications delay and a > layer of fragility to keyserver queries. Have you ever run "gpg > --refresh-keys" on a keyring with several hundred entries? Yes, this takes long even without TLS > My threat model is a motivated attacker looking to glean information > about the relationships of interest to a particular entity based on > their keyserver queries. Since many keyservers are on fairly public > network segments (in colocation facilities, for example), the > opportunity for sniffing traffic at the very least is high for an > attacker with moderate resources. A big local keyring will be helpful. The only problem is that gpg is too slow for this. For refreshing keys you would randomly select some keys to refresh in addition to those you really need to refresh. > servers and clients using SSH and TLS). Regular connections to a > keyserver to check for updated keys, etc, can leak a significant amount > of information about (for example) who is authorized to access a given > service. A large organization using OpenPGP for this type of The question is how to setup a reliable revocation service. I don't think that keyservers are the proper solution. Keyservers have a similar problem as CRLs do. OCSP has other problems - it is all a mess. We better don't mix this up with the TLS thing; that might be useful even without a reliabale revocation service.. > Could you point me toward some examples or something i should read up on > to better understand the vulnerabilities? Without functional revocation > certificates, the OpenPGP infrastructure is significantly weaker than > i'd like it to be. We learned in the past that some keyservers garbled the OpenPGP keys. We have some fixes in gpg to remove invalid packets and those packets might be revocation certificates. It does not happen often but keyservers employ similar code and we don't know what people can do with a targeted attack on the keyservers and thus eventually on gpg. Right that will be DoS - people will in turn not refresh their keys to avoid the trouble of waiting to send out the encrypted mail. > Could you propose a different mechanism that you feel is superior? I'm > happy to evaluate alternatives, as i quite like the public keyserver > network as i understand it (though i'm concerned by your unsettling > remark above about the ease of corruption of public keyservers). The data on the keyservers will technically not get corrupted but a DoS would add so man valid packets to a keyserver that the net effect of such a DoS is the same as corrupted data. Consider a well known key, with a a couple of thousand bogus signature packets and the time it takes for the keyservers and far worse for all clients to filter them out. > I hope moving this to gnupg-devel is the right place. It may also be > relevant to ietf-openpgp if you have serious qualms about the utility > revocation certificates in general. It may also be of interest to OpenPGP provides the message format but no operational advice on how to setup a PKI or a revocation services. Thus this is out of scope for the WG. However, we have used the WG list for such discussion in the past because all the OpenPGP people should be on this list, which is not the case for gnupg-devel or sks-devel. The format is not the problem, the reliable service is the problem. Salam-Shalom, Werner ps. Sorry, for the late replay, I was a bit too busy with other projects the last weeks. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
