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

[David Shaw]

On Mar 8, 2009, at 3:50 PM, Daniel Kahn Gillmor wrote:

> 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?

Oh, no worries about objections.  I was just stating a fact: I made up  
the port number.  If you have a better one, I genuinely want to know  
so I can use it.

The same code will (more or less) apply to gpg2.  Most of the changes  
I make are for both code bases, but I usually work on gpg1 then batch  
up my changes onto gpg2.  I have to find a spare few hours and do the  
code integration.

> * 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)

GPG does have the necessary concepts for this.  There is already code  
for handling such a TLS upgrade in the LDAP handler, as well as  
various levels of upgrade enforcement (don't try / try but fail  
quietly / try but fail loudly / require upgrade).  The problem is that  
RFC 2817 never really caught on for one reason or another.  Apache  
supports it, but offhand, I don't know of any clients that do,  
including libcurl which is what GPG generally uses for HKP keyserver  
support.

We may end up with "hkps" on port 11372 just for lack of support for  
doing anything else.

David