[openpgp] draft-dkg-openpgp-abuse-resistant-keystore-03

[Phil Pennock <[e-mail]>]

Daniel,

Still loving this document overall; there's lots of overlap with some
design notes I had for an SKS replacement, back when I was thinking in
terms of onion layers of filters to be able to interoperate via the SKS
protocol but restrict what was sent.  But frankly, I no longer want the
cesspool data on a machine which lands me with liability, so I've junked
that idea.  Although I had some stuff around tombstoning and I needed to
investigate how the SKS reconciliation protocol could be ... cheated.

I settled on "we" rather than "you" below; I don't mean to presume, I
just mean "in it together" as opposed to "all this is on you".

In some of the below, some of my thinking from that project carries
forward, including the idea that advanced operations can be performed
with a dedicated client which can PGP-sign action directives to
the keyserver, to authenticate certain actions, as long as the signing
key is "sufficiently trusted", which might be "is in the strong set" or
might be "ACL".  (Or "in the strong set and matches domain X via direct
trust path from master key in X crossing only signed uids in X").

Perhaps a section 1.3 as a caveat to readers in the far far (far)
future, explicitly noting that restrictions on fingerprints vs keyids
are based on an assumption of V4 keys per [RFC4880] and that a future
revision is expected to make the fingerprint be the keyid.  I'm sure
that 4880bis will be published one day.  Or perhaps 13.2 is better
(except that there are earlier mentions of the issue).

(Are there any gotchas around V3 keys which we should mention?)

In 5.1.4 the hinting for redacted user-ids hard-codes SHA256.  Given
that this is just hinting to match existing data from the query, I'm
having a hard time seeing how a SHA2 family attack would lead to
problems here, so simplicity says to leave it as is, but it feels
strange to introduce algorithm inagility (creakiness?) to OpenPGP.
Besides, just because I don't see the problem doesn't mean it doesn't
exist.

All tools which are going to match are going to be using OpenPGP parsers
anyway.  Can we just prepend the one octet hash algorithm code, but
specify that SHA256 is the only algorithm which SHOULD be implemented,
both client and server, barring future cryptographic breaks and failure
mode revelations?

In 5.1.5, what is the threat model?  We seem to be switching to
protecting an innocent client Alice from malicious upload by Mallory via
redaction, to secrecy in public key data and letting untrustworthy
client Ursula retrieve keys via fingerprint (which they must already
have) but try to prevent Ursula from knowing what was in a self-attested
identity?


I wonder if there's a model for a section 6.6, where keys can be
tentatively accepted via bearer token in the upload process, to
facilitate PGP keysigning parties?

I'll outline my loose thinking for this, in a way which is far too
specific for the draft, but might trigger you thinking of even better
approaches.

My loose thinking for this is that anyone organizing a keysigning party,
if they're already in the strong set, would issue a directive
(aforementioned client tooling protocol, request signed by their key, so
the keyserver evaluates and trusts) create a keysigning event,
first-come first serve "Phil's Example Conference 2019" for instance,
with associated expiration date, and be issued a bearer token which can
be used for upload.  I suspect that GnuPG would accept a simple patch,
but really the client upload of a key is then just a curl(1) invocation.
This puts the key into a group where general retrievals won't see it,
but specific event retrievals will (second part of needed GnuPG
integration, to give an event code or something, without needing the
bearer token).  Bearer tokens will leak, but not too fast.  Folks can
upload.  Any key which gets enough cross-signatures will be promoted
out.  A nice UI could even give summary sheets for printing attendee
lists with fingerprints.  The upload might even trigger mandatory email
address verification, so that party attendees might stop doing the caff
thing and instead stick to validating human names and rely upon the
service to have validated any email addresses they're signing.  Because
seriously, even amongst PGP keyparty folks, the number who bother with
caff(1) is vanishingly small.  I think I'm one of a number who I might
count on the fingers of one hand, that I've encountered who actually do
that.  We can improve the ecosystem here.

Other approaches are to just say "run a dedicated simple PGP keyserver
for the event, we'll try to upload afterwards", in which case the 6.6
becomes something around authenticated upload for dedicated event
keyservers, suggesting that "login" might be appropriate.

Which leads to a thought: the models of accepting keys don't seem to
include "non-PGP login".  Eg, SAML integration to let the employees of a
company upload PGP keys and strip the uids down to those which include
their email address, or policy-allowed groups therefrom.  This would not
be first-party-only.

So a contextual mitigation is "identity known to keyserver by
external-to-OpenPGP means".  SAML based OAuth2 flow being the example
which makes most sense to many organizations.  Or is this covered under
6.4, exterior process?  In which case, I think it's a suitable second
example.

This might also factor into a valid criterion for section 10.

Before moving on: how do PGP keysigning events factor into IP
rate-limits?  Part of my thinking here, with conferences behind NAT, is
that ratelimits might be raised for the bearer-token uploads.


7.1 nit: "if the keystore have a" : have -> has

7.4: earliest by revocation date ... this seems to open a window for
confusion if Mallory generates a new hard revocation with text saying
"superseded by this key 0x1234...4321 which you should trust, no
really".  Humans pay attention to that, even when they shouldn't.

I think a keyserver should remember both the earliest by revocation date
and the first one seen.  We'd just have to accept that in a peering
system, if Mallory can race out a different revocation, then different
revocations might be presented and some people will get untrusted text
pointing the naive to a bad key.  No worse than the current situation,
but better than "spec says we have to propagate the reason for whomever
generates the earliest claimed time".  The one situation which has me
being more careful about time-windows is generate-time revocation
certificates being typed in and uploaded.

7.5: I was thinking before that there's an argument for "don't reveal
any PGP keys which don't have a timestamp from the past 3 years", where
the timestamp of an updated self-sig would be sufficient.  If a human
hasn't done a keep-alive in that time, let the key stale out of the
system.  Just move those keys to the graveyard, where they can still
participate in web-of-trust reachability calculations, but not be
retrieved.  Interesting points here around "what about attestation sigs
on other keys?  If K1 signs K2, does that extend the life of K1?" and
"if we keep keys in the graveyard to preserve WoT and signing another
key doesn't preserve life, does this prevent _new_ WoT links with
signatures after the date, until the key is brought back to life with an
updated self-sig?"

10.1: should No-modify have any impact on keyservers not following the
section 10 model?  "Don't accumulate signatures by third parties"?  Is
this actively helpful?  It seems that GnuPG is setting this by default
and I don't know why.  My main key and my new work key (generated by
GnuPG 2.2.15) contain it and I know I didn't explicitly request this
last week.

13.3.1 nit: potenitally -> potentially

14.3.1 : a local-part can be a quoted string.  These are valid email
addresses (by explicit configuration, not catch-all):

  "X'); DROP TABLE domains; DROP TABLE passwords; --"@spodhuis.org
  "<script>alert('Boo!')</script>"@spodhuis.org
  a~`*&^$#_-={}'?[e-mail]

I haven't double-checked lately but all of those should reach me.  One
didn't even need quoting.  I've not yet had spammer web-scrapers pick
those up despite repeated mentions in public mails.

14.3.3 fixme appears to be truncated

16.4 nit: "How should in interpret" in -> it

16.8 : should there be a warning that encryption to a pool system may
not offer the privacy expected?  Feel free to lift text from:
  <https://www.openwall.com/lists/oss-security/2017/12/10/1>


Not covered so far (AFAICT):

Operational threats to keystores: if the public pools are run by
volunteers, traffic abuse becomes an issue.  Eg,
  <https://www.openwall.com/lists/oss-security/2018/08/26/1>

Beyond the threat to willingness of folks to offer gratis service to the
public, is also there value in a section on good practice around not
even needing to use keyservers?  Avoiding being the abuse, or just
resilient configuration.

Regards,
-Phil