Bug#519333: gnupg: Please include support for encrypted keyserver queries [PATCH]

[Daniel Kahn Gillmor]

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, dkg at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090323/7a1a8d1c/attachment.pgp>