key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

On 13/06/18 14:43, Daniel Kahn Gillmor wrote:
> the proposed revocation distribution network wouldn't allow any user IDs
> or third-party certifications, so most of the "trollwot" would not be
> relevant.

As I see it, the keyservers perform two related but distinct functions -
finding unknown keys by UID, and finding updates to known keys by
fingerprint.

All the current issues are related to the first function, but the first
function has several alternative solutions available (DNS, WKD, Keybase,
attaching pubkeys to every email...). If this first function were to
fail overnight, it would be an inconvenience but not a disaster.

But there is no known alternative to the second function, which is the
distribution of key updates, including revocations. Therefore I believe
the immediate priority should be to protect update distribution.

How to prevent abuse of a distributed, unauthenticated store of
arbitrary data remains an unsolved problem (see: usenet). If the
keyservers are to remain unauthenticated and distributed, then the only
option is to prohibit arbitrary data. That means no arbitrary data
fields (i.e. no UIDs) and no arbitrary data in structured data fields
(i.e. validity checks on self-sigs). This will shrink the size of the
database significantly, but impose some processing cost.

There are two ways forward: a new network of key-material-only servers,
or restricting the existing network to key material only. In the first
case, we would still need a means to propagate keys between the old and
new networks during the transition. And in the second case, we would
need to handle an intermediate state where only some servers have been
upgraded to the new version.

So no matter what we do, we will still need to have some method of doing
fake recon with legacy sks instances. The question is how to arrive at
this state most efficiently. I would suggest that since recon is at the
root of the problems, we should concentrate on the recon process itself.
If uploading a bad key takes down one server then fine, we can lose one
server. But the badness must not infect other servers automatically.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180716/10c4112e/attachment.sig>