[Sks-devel] Key updates not propagating

[Andrew Gallagher]

Hi, all.

I extended the expiry on my key (0xfb73e21af1163937) over a week ago and
uploaded it to the pool. I foolishly thought that doing so a few days in
advance of its expiry would be sufficient. Not so. Even today, I see
that many pool members still have not received my new self-sig.

This has caused much disruption on servers that have monkeysphere
configured - logins are still failing at random depending on what pool
server they connect to. Given that dirmngr is a persistent background
process, the DNS round robin doesn't shuffle the pool as fast as you
might think. Clients that hit a bad pool member keep hitting the same
bad pool member until the dirmngr process is restarted. Today I had to
kill dirmngr on one particular server *twice* before it found a good
pool member.

I don't believe this non-propagation is simply a result of bad
connectivity - I can see one "bad" pool member (sks1.cryptokeys.org.za)
is connected directly to the "good" pool server (pgpkeys.urown.net) that
I uploaded my self-sig to. sks1.cryptokeys.org.za has not been correctly
gossiping with *any* of its peers for over a week, and yet remains in
the pool.

Also, to my surprise, one of the high-performance nodes (pgpkeys.hu) is
a "bad" pool member that has not yet discovered my self-sig. I suspect
this is because it is weakly connected to the rest of the pool, and
intermittent gossip failures have left it semi-detached.

All this is an enormous red flashing light.

If the pool members are not mutually well-connected, then uploading a
key (or more importantly, a revocation) to the pool is not a guarantee
that a client that connects to the pool will receive that information in
a timely manner. The basic assumption of a decentralised store of
information is broken.

I have not been running a keyserver myself since the first poison-key
incident. Given the ongoing poison-key problems I am unlikely now to
ever run one again, unless the entire codebase is overhauled. I have
neither the time, energy nor skillset to perform this task, and it is
becoming clear that nobody else does either.

This is not anyone's fault. It is just an unfortunate reality that we
have to accept. SKS is end-of-life.

WKD is a useful and simple tool for finding keys that match email
addresses. We do not need the keyservers for this any more. What WKD
does not provide is twofold:

1. A way to search for keys that do not correspond to email addresses
(e.g. code signing keys)
2. A way to refresh key validity (self-sigs and revocations)

I suggest that we start by solving these two narrow problems.

Might it be possible to replace the keyserver network with a lightweight
URL redirection service? This would remove the requirement for the
keyservers to host any data at all, solving multiple problems in one
stroke. The main disadvantage would be that it would be simple to block
timely distribution of revocations - but right now this isn't happening
anyway.

Thoughts?

-- 
Andrew Gallagher

signature.asc
Description: OpenPGP digital signature