I'm moving this discussion about the merits of TLS-wrapped HKP to gnupg-devel. People just coming into the thread now can catch up on the history at http://bugs.debian.org/519333
On 03/23/2009 11:32 AM, Werner Koch wrote: > On Mon, 23 Mar 2009 15:17, d...@fifthhorseman.net said: > >> certificate retrieval via cleartext HKP over tor does not: >> >> * assure me that the host i'm connecting to is in fact the keyserver >> which i trust to return reasonable information, or > > Who cares? you don't have any control over the keyservers and what ends > up on the servers. Nor do the keyservers can control this. 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: * never logs keyserver queries. * has well-documented and -followed machine hygiene/maintenance policies, making the machines less vulnerable to compromise. * runs free software that i can inspect for "phoning home" or escrowed access (backdoors). >> * assure me that data has not been tampered with in transit between the >> tor exit node and the keyserver, or > > OpenPGP keys are self-contained. Thus this is not an issue. 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 with specific notations), which would have adverse consequences for the user. >> * hide my queries from an snoop on the same network segment as the >> keyserver or anywhere between the tor exit node and the keyserver. > > See my comment on gnupg-devel; given enough traffic to the keyservers > optionally with filler queries, it is not worse as with any other use of > tor. Or in short What is your threat model? But not all keyservers have enough guaranteed traffic, and not everyone wants to (or can afford to) saturate the network with filler queries. 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? 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. I should probably point out that i'm also interested in using keyservers in connection with active network sessions (for mutually authenticating 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 authentication could run its own keyserver hooked into the public gossip, and encrypt queries to avoid this leakage while still taking advantage of regular updates. The monkeysphere project (http://web.monkeysphere.info) currently uses keyservers in this way to mutually authenticate ssh connections. Some administrators have already suggested would be more interested in deploying this infrastructure if they were able to use private and integrity-checked connections to a keyserver of their choice. I don't believe that tor alone fulfills this requirement. > Anyway, > revocation certificates don't really work. It is too easy to corrupt > data on keyservers. This is a serious concern, and i'm embarrassed to say it's news to me. 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. I'd like to figure out how to make them work, if possible. > You should resort to a different mechanism for key retrieval that the > ad-hoc network of public keyservers. 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). >> While tor is certainly a good option to obscure where i'm connecting >> *from* (something which hkps does not achieve), it does not meet the >> same goals as a TLS-wrapped connection to a keyserver. > > I don't think that this bug tracker is the right meida to discuss such > stuff. 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 sks-devel, whether you believe that the corruptibility of public keyservers is due to implementation issues or protocol flaws. Thanks for your feedback, Werner. This is a useful discussion for me, and hopefully others. Regards, --dkg
signature.asc
Description: OpenPGP digital signature
