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

[Daniel Kahn Gillmor <[e-mail]>]

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/

Thanks to all for the discussion around this draft.  I've tried to
incorporate some of the feedback i've gotten, and added more mitigations
and considerations, producing version -01.

Substantive changes between -00 and -01:

 * split out Contextual and Non-Append-Only mitigations
 * documented several other mitigations, including:
   - Decline Data From the Future
   - Blocklist
   - Exterior Process
   - Designated Authorities
   - Known Certificates
   - Rate-Limiting
   - Scoped User IDs
 * documented Updates-Only Keystores
 * consider three different kinds of flooding
 * deeper discussion of privacy considerations
 * better documentation of Reason for Revocation
 * document user ID conventions

The source for draft -01 is attached to this message, and remains
available for merge requests and open issues at:

  https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore

The most unsettling evolution of my own thinking on this has to do with
clarifying the inherent tension between accepting unrestricted public
certificate uploads and permitting useful certificate discovery (by user
ID). (see the final paragraph of the security considerations section)

In a world where the public contains people with malice (our world), i
think we can't have both of those features due to user ID flooding. This
has unfortunate implications for use cases that depend on public
keyservers for both certificate discovery and unrestricted upload.

This isn't a particularly novel or surprising insight, but it's
definitely sad, since that was a nice set of features offered by the
keyserver network, but i don't see how it can possibly be sustained in
the face of deliberate attack.

The implication is, i think, that we need to think differently about
certificate discovery in most cases.  In particular, i'm thinking that
we really do need to expect in-band certificate discovery where
possible, falling back to reliance on a deliberately curated keystore
(which means being vulnerable to the curators).  We'd then mainly to
rely on public keystores for certificate update (and not for discovery).

Finally, i'd like to call people's attention to § 9.3 ("Assessing
Certificates in the Past") -- this suggests that either our keystores
need to be append-only (which is sad because of the risk of growth
without bound) or we need to acknowledge that they can only reliably be
used for online verification.  Again, in-band certificate mitigation
might help with this (i.e., distributing some form of certificate
alongside the signature that needs verification, which can then be
merged with any updated information from public keystores).

    --dkg