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

Hi Micah--

Thanks for the thoughtful review and feedback.  sorry it's taken me a
little while to integrate it.  Some thoughts below:

On Mon 2019-04-08 10:06:36 -0700, Micah Lee wrote:
> 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'm not sure i understand this concern, so i want to unpack it a bit.
If you've got specific text you'd like me to add after this discussion,
please do suggest it!

First, a bit of pedantry (sorry!): i think the attack that you're
describing is *not* someone impersonating your certificate, but rather
someone impersonating your user ID.  Is that what you're talking about?

I've labeled the abuse-detection action you're describing as "identity
monitoring" in draft -03.

However, if flooding a given user ID makes certificate discovery
impossible, then flooding a given user ID *also* makes "identity
monitoring" impossible.

So, i think what you're describing is an interesting tension -- but one
that presumes some sort of authoritative nature for the keystore in the
first place, in which case perhaps the authoritative element is where
the appropriate filtering comes in, right?

> 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.
I think you're making an argument that all keystores should do
cryptographic validation.  That has interesting implications, given that
there might be use cases where it's useful to distribute certifications
issued by keys that the keystore doesn't know about.  I welcome textual
suggestions that improve this guidance in the current draft!

> 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.
I agree, the user interface for a keystore (if any exists) needs to make
clear what work it has done to vet the data it offers.  I've added a few
paragraphs about user interface to the draft, and would welcome
clarifications there.

I don't want to make the document particularly elaborate in its
discussion of user interface, because (a) the IETF isn't a particularly
good forum for user interface discussion currently, and (b) many
keystores have radically different UI/UX scenarios, and (c) full user
interface details seem like they might warrant a distinct discussion
that is more implementation-specific anyway.

My current approach is to imply that a keystore has an (abstract)
three-part API of "certificate submission" (new data proposed for
inclusion), "certificate update" (certificate retrieval by fingerprint),
and "certificate discovery" (certificate retrieval by user ID or
substring match).  I touch a bit on other potential API endpoints in the
text.  If you think i'm missing something, please point it out!


> 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.
I've added a section on global append-only logs ("blockchains") to draft
-03.

> 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.
This is a useful insight, and i've tried to document it in -03 as well.
I welcome text to improve it.

> Finally, I found a few typos saying "certiifcate" instead of "certificate".
thanks, fixed!

        --dkg

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp