Re: [openpgp] Modelling an abuse-resistant OpenPGP keyserver

[Micah Lee <[e-mail]>]

On 4/6/19 7:47 PM, Daniel Kahn Gillmor wrote:
> On Thu 2019-04-04 18:41:14 -0400, Daniel Kahn Gillmor wrote:
>> I've documented some thoughts on how to resist this abuse in a new
>> Internet Draft:
>>
>>    https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/

Hey dkg, thank you for putting in the work to write this draft. It's
very necessary, and I think you lay out the problems and mitigations
well. Here is some feedback.

In section 2.2, the draft says: "If the keystore does not offer a
discovery interface at all (that is, if clients cannot search it by user
ID), then user ID flooding is of less consequence."

I completely agree with the (unfortunate) sentiment that searching by
user ID is not appropriate for key discovery, because user ID flooding
is trivial. However supporting some advanced querying of data in the
keystore, including by user ID, may be useful for non-key discovery
reasons, like to determine if someone else is impersonating your
certificate.

I also think it's worth adding a mitigation that specifically deals with
this SKS Keyserver bug [1], probably in section 3. There is never a
legitimate reason for a certificate to contain a user ID packet with a
signature that doesn't verify, or with a signature that verifies using
any key other than the certificate's primary key. If such user ID and
signature packet pairs are found, they should always be rejected.

The same (I believe) is true for revocations, except in the case where
there's a "designated revoker" (I have never used this feature of
OpenPGP, so I could be wrong here). Any revocation and sig packets,
where either the sig doesn't verify, or verifies but isn't signed by
either the primary key or the designated revoker key, should also always
be rejected. Otherwise, people can abuse the keystore by fake-revoking
other people's keys (which SKS is currently vulnerable to).

I also think that it might be reasonable to add a section about user
interfaces, specifically to avoid the issue that this SKS Keyserver pull
request [2] tries to fix. (This PR was approved in June 2018 but has not
been merged, and no releases have been made since then; the project
appears to be abandoned.)

At the moment, SKS keyserver provides a web interface that the public
often uses for key discovery, as well as to link directly to their PGP
certificates (for example, journalists provide these links in their
Twitter bios). But this interface shows users provably-malicious data
(like user IDs and revocations with signatures that don't verify).

If an abuse-resistent keystore wishes to provide a UI at all, as opposed
to just an API, then the UI should focus on protecting users from abuse,
and make it clear that certificates don't necessarily belong to the
people or email addresses in the User ID packets, and, if the keystore
doesn't reject malicious user IDs and revocation certificates, make it
clear that all of the information displayed about the key might be
inaccurate as displayed through that UI. But, perhaps a better option is
that the keystores should not provide a UI at all, and instead only
provide an API.

Also, as others have pointed out in this thread, I think that hosting a
keystore using modern distributed blockchain technology is a good idea,
and one of the few genuinely useful uses of blockchain technology.
Storing data in a blockchain is also much more reliable than keyservers
that periodically sync with some set of other keyservers, because every
keystore will have an exact copy of all data, rather than various
keystores having various different states of the data.

Section 5 is dedicated to "non-append-only mitigations", which wouldn't
work with a blockchain. However I think that all of these mitigations
could be applied at _query time_, which would allow the keystore itself
to be append-only, but still provide users with the same resistance
against abuse as if this data was dropped at write time.

Finally, I found a few typos saying "certiifcate" instead of "certificate".


[1]
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41/web-app-displays-uids-on-keys-that-have
[2]
https://bitbucket.org/skskeyserver/sks-keyserver/pull-requests/59/add-disclaimer-to-html-template-educating/diff