Keyservers and GDPR

[Phil Pennock]

On 2019-05-26 at 10:43 +0200, Werner Koch wrote:
> On Sat, 25 May 2019 14:53, ilf at zeromail.org said:
> You mean from the left over 5 servers in the default hkps pool:
> 
>  pgpkeys.eu       51.38.91.189    AS16276 (UK)
>  pgpkeys.uk       192.146.137.98  AS57672 (UK)
>  pgpkeys.co.uk    192.146.137.99  AS57672 (UK)
>  fks.pgpkeys.eu   46.4.246.179    AS24940 (DE, Hetzner)
>  keys2.kfwebs.net 37.191.231.105  AS57963 (NO) 
> 
> which according to rumours have only two or three different operators?

My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu
maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests
Daniel runs that one too.  That covers the first four.

kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system
and sks-keyservers.net.

hkps is limited because Kristian doesn't hand out certs to anyone who
shows up with a new keyserver and asks; he tends to do so with people
who've been around and part of the community, because of the fairly
obvious problems with assuming TLS is buying you anything when entirely
unknown-to-others folks run the servers.  Kristian takes a lot of flak
for not giving people the power they want just because they ask for it.

With the various problems of SKS today, I tentatively suggest that not
defaulting to the HKPS pool and choosing a different target for the
keys.gnupg.net CNAME might be beneficial.

<https://sks-keyservers.net/overview-of-pools.php> has the criteria; I
suspect that >> subset.pool.sks-keyservers.net << is likely to be the
best choice for GnuPG; the meaning of "subset" changes over time,
picking newer servers, but for a while now that's been "updated SKS
software able to handle Curve25519 keys".

Spitballing crazy design now:

The only way to get back HKPS while still having diversity and yet still
some accountability is likely to be by requiring DNSSEC-signed
reverse-DNS which points to matching DNSSEC-signed forward DNS to prove
domain matching, and a trigger record in DNS indicating to use TLS; once
there's a forward-name which doesn't require central coordination, you
can verify normally and "anyone" can run a keyserver again.  With all
the pros and cons that entails.

GnuPG can pretty much define what it wants here.  Including changing the
URL scheme name if needed to avoid confusion.  TLSA records are
available for opportunistic TLS.  Effectively, "DANE for HKP with
work-arounds to handle the pool nature and bounce into a verifiable name
for arbitrary pool names".  Shove a TLSA record in reverse DNS to
indicate it's supported and you're good.  Hrm, probably don't strictly
need the reverse DNS to be DNSSEC-signed, as long as the
TLSA-or-other-marker is present and the forward DNS is still signed.

There's ways around it, but none of it will make folks who object to
DNSSEC happy.  Tough.

-Phil