Keyserver/security bug 1447 (and 1446 too)

[Phil Pennock]

On 2012-12-03 at 11:04 +0100, Werner Koch wrote:
> What root CA is to be used?  One of the usual PKIX ones or a dedicated
> for the pool or all keyservers?  If the latter, who is in charge of
> creating the certificates?

The root CA happens to be private, what matters is the intermediate CA
which signs the certs.  The certs are signed by the operator of the
pool.

> Do you demand the servers should use a certificate issued by the pool
> operators (e.g. as Sub CA)?  Or shall they merely use the pool name as
> an alternative server name?

We settled on "all clients are sending SNI nowadays, so we can safely
dispatch on that, knowing that any client not sending SNI probably isn't
verifying anyway".

So the TLS handshake sends ServerNameIndication, which is used for
selecting a server-side vhost, which includes a certificate which covers
that SNI hostname.

So: any given keyserver operator can be a member of an arbitrary number
of pools.  Any pool which wants to be sure that clients _can_ validate
can liaise to have a vhost which is pool-specific, using the correct
key/cert for that pool.  There's no exclusivity or lock-in, and
keyserver operators can work with whatever pool operators they trust to
do a competent enough job and not create headaches down the road.

Kristian's doing proof-of-concept work and pushing the boundary of
improvement here.  I can fully understand the GnuPG folks wanting to
ensure that they run the root CA used for any default verification by
GnuPG and wanting to work with keyserver operators.  So I for one am
happy to add a cert for a keys.gnupg.net hostname issued by the GnuPG
folks.  (The trust in the other direction is a different issue)

At present, my main SSL vhost uses a cert issued from my private CA,
which provides as much assurance as anything ever did in this realm but
isn't so useful for others.  It includes (and has for a year or so)
keys.gnupg.net as a subjectAltName.

The difference would be changing the vhost used for that name and giving
it a different cert.

> Why do do you think the pool's name is more trustworthy than the
> individual server name?  We are still talking about round-robin DNS,
> right?

The pool name was set in ~/.gnupg/gpg.conf or given with --keyserver, so
has been chosen and passed to the tool via some trusted path.

> The problem is more that you want to use PKIX for a system which was not
> designed for it.

No, we're using PKIX for security host-to-host communications with TLS.
The problem is that a common library makes it hard to do the right thing
in the presence of SRV records.

By contrast (to respond to another person here), using PGP for link
security instead of the X.509 PKIX tells me that folks are iffy on
"message-based security" vs "live link security" and on the impact of
timing-based attacks.  As a keyserver operator, someone happy providing
a public service to assist in OpenPGP usage, I'm not going to put
PGP-based link security into place without a lot more operational impact
analysis of the crypto code in GnuPG's resilience to timing attacks, and
more.

Both models of security have their place.  When used correctly, they can
complement each other well.

We're using PKIX for what it's designed for, in such a way as to
actively preserve privacy of people using PGP clients if they use an
hkps:// keyserver they trust.

Regards,
-Phil