Re: [Sks-devel] details to configure SKS https web interface

[Daniel Kahn Gillmor]

On 03/07/2009 09:37 PM, David Shaw wrote:
> On Mar 7, 2009, at 7:30 PM, Daniel Kahn Gillmor wrote:
> 
>> We also are listening on port 11372 because this seems to be the choice
>> of gnupg maintainers for hkp-over-tls (hkps?), according to this recent
>> (as yet unreleased) patch to gpg:
>>
>> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?root=GnuPG&rev=4924&r1=4878&r2=4924
> 
> I wrote that patch, and I picked 11372 simply because it was 11371+1. 
> If someone feels a different port would be better, let's talk about it. 
> The code hasn't been released yet, so it's very easy to change (it will
> get harder to change once there is a release).

I didn't mean to imply that i had any objection to it -- it seems
reasonable to me, and in keeping with what seems to be the dominant
practice in a lot of scenarios on today's network.  I couldn't find a
parallel patch in the gpg2 codebase.  Do you plan on a similar approach
there?

RFC 2817 [0] (which is ancient in itself) suggests that the practice of
direct TLS-wrapping a service on a different port should be deprecated,
and provides a mechanism for upgrading a non-TLS mechanism to use TLS
(analogous to how STARTTLS is used for IMAP and SMTP).

While i'm not suggesting that this is the only way to go, i do think
this seems like it might be a reasonable approach to consider.  What
would be needed to handle this for the interaction between SKS (which
appears to be the dominant free OpenPGP keyserver today) and gpg (which
seems to be the dominant free OpenPGP client today)?

 * SKS would need to be able to switch to TLS using the Upgrade: mechanism.

 * gpg would need to be able to initiate an upgrade, and gpg users would
need to be able to configure gpg to indicate that non-upgraded HKP
sessions should be rejected. (this would protect against MITM
session-downgrade attacks that strip out the upgrade request/response
traffic)

These seem like useful but non-trivial tasks, so i suspect that the
current (simpler) implementation is probably the right one, since it
gives us TLS-wrapped HKP relatively soon.

I'd be happy to hear other people's thoughts on this.

        --dkg

[0] http://tools.ietf.org/html/rfc2817

signature.asc
Description: OpenPGP digital signature