Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt]

Jon Callas <joncallas@icloud.com> Sat, 31 August 2019 00:04 UTC

Return-Path: <joncallas@icloud.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31211208FB for <openpgp@ietfa.amsl.com>; Fri, 30 Aug 2019 17:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O01zMavKDMxN for <openpgp@ietfa.amsl.com>; Fri, 30 Aug 2019 17:04:08 -0700 (PDT)
Received: from mr85p00im-ztdg06011101.me.com (mr85p00im-ztdg06011101.me.com [17.58.23.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C093B1200F7 for <openpgp@ietf.org>; Fri, 30 Aug 2019 17:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1567209848; bh=I/dENcZS+SXDCqus/ewq++QedZEArvz+grAvB78WjKM=; h=Content-Type:Subject:From:Date:Message-Id:To; b=FhjBWqmXXQrt3wl9cZhY+IHXB0dtOi4FgYYwn0YSyiJ9KnRGLEG6d/Njy+715dNHX w1Hio4LJTFS/2qPc/k7mERFE8EirvqMYQeonzaDQnCohqmQqyNJIBeMvHjZpxPwplh LL9PgLdwPvcPVq5APhMEGxQmT6y0RDZ2xhbpiW44u6sWq5IXwI8v6RPcvBEsFPMQpF 5+hSFXXwK+GLTcn9DC9Dzy7nl+mVUfaNIonzwR//3VwWSzxVjXZlCEKIkZntyxSe9u xgHUPuU3BNtAxkk6bg8HT6sQjt7FNVPBD4956Xxiww6Yn4XxhJ79ccOhXeRXuIspVo lFPTEdWVGqByg==
Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06011101.me.com (Postfix) with ESMTPSA id 10E054A0981; Sat, 31 Aug 2019 00:04:08 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Jon Callas <joncallas@icloud.com>
In-Reply-To: <87imqh9bgr.fsf@fifthhorseman.net>
Date: Fri, 30 Aug 2019 17:04:07 -0700
Cc: Jon Callas <joncallas@icloud.com>, openpgp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AF6DE59-F071-4DA9-AF69-1C21A202D181@icloud.com>
References: <156650274021.14785.10325255315266801149.idtracker@ietfa.amsl.com> <875zmodi1v.fsf@fifthhorseman.net> <8736hsdfm4.fsf@fifthhorseman.net> <CAF751FB-4AFD-4E64-AD8C-E04B3031F50D@icloud.com> <87zhju9qlb.fsf@fifthhorseman.net> <6057F53D-2251-4B92-997B-EF241C2F4EF3@icloud.com> <87imqh9bgr.fsf@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-30_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908300237
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/kkWulCbthqLP6gnxP5Was-dPHz8>
Subject: Re: [openpgp] Revocations of third-party certifications (TPK+"CRL") [was: draft-dkg-openpgp-abuse-resistant-keystore-04.txt]
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Aug 2019 00:04:11 -0000

Thanks for the comments as well, and I'm really glad you're taking this task on. It's been one of my peeves for a long time. I know you've been dealing with it at least in part because the issues have been inflicted upon you, too.

I want to pull back and take a number of the discussion points in text paragraphs, too. I think we're mostly in violent agreement.

One way that I think about this is that the server is an actor in the interactions, and I'd encourage a server to have opinions and policies. We tend to look at the security actors as Alice and Bob, but the server is also an actor and should consider both Alice and Bob as potential adversaries.

There's two broad classes of abuse that we have to deal with. I'm going to call them syntactic abuse and semantic abuse. Syntactic abuse is something that is often relatively easy to discuss and solve. For example, if Alice puts a 1GB signature or revocation on Bob's key, we can solve that easily. Discussions we have had are pretty non-controversial and I like your suggestion about minimal revocations. 

There are other forms of syntactic abuse that's similar -- for example, if someone put a million certifications on a key, that would suck. The server could guard against with a policy like stripping certifications from a key that's not on the server. The obvious workaround for the abuser is to upload that million keys first. I still think that a policy (possibly per user?) of stripping certifications from keys not on that server is not a bad idea. I can imagine others, like not allowing Alice to submit certifications other than her own. Nonetheless, there's a lot of potential issues here and I agree with you that some of the things we discuss aren't sufficient, but I'll bet that a few (like syntactic parsing and size limits) are necessary.

One part of abuse protection is going to be to have a cleaner function that will do things like take the submitted certification and return a clean version of it. I'd include in that some hygiene functions like stripping expired certifications (except self-sigs), and so on.

Semantic abuse is different and much of that's going to be in the eye of the beholder. I think one might argue that something like many certifications as a form of spamming is actually semantic. Much of that's going to be in the eye of the beholder. In many cases, the only one who can tell us if Alice is being abusive to Bob is Bob.

You gave the use case of Alice revoking her certification of Bob's key because she believes he's suffered a key compromise. Fair enough, but what if she thinks that for some legitimate, but eccentric reason. Oh, let's suppose Bob says he keeps his passphrase in a password manager and Alice is horrified, and thus wants nothing more to do with Bob's key? 

Here's a case where I think that we're more or less in violent agreement on "ownership." I think it's Bob's key and if he wants to delete Alice's certification+revocation, fine. Let him, it's his key. The place where I think we agree on concept but perhaps not on the word "own" is her certification. Certainly, we shouldn't be seeing Alice's certification re-appear without its revocation. Whatever term we want to use to describe that is fine with me. As long as we are ending up with the idea that the revocation sticks to the certification and can't be removed, we're on the same page.

You noted that we're probably going to need to have a way to tombstone a certification. I agree. If Bob deletes Alice's certification, we don't want it to reappear. My hand wave back in 2440 days was the flag that says "let me manage this key, myself" which yes is a large hammer, but it works. If Bob's key is groomed the way Bob wants it, it's not abusive -- given that we agree that Bob owns his key. (There are people I know who disagree with this, but let's ignore them for now.)

If I were writing a server, I'd implement the tombstones with a non-exportable signature made by a key that the server itself owns. I'd write the tombstone details in a notation. This leaves dangling the issue of how it gets propagated, as you noted, and I'm willing to leave that as an exercise for the future. I'll state the problem though: Bob deletes Alice's certification from his key; how does Charlie find that out?

Let's rewind, though and come back to Alice's revocation. Let's consider the case where Alice really is trying to make Bob mad. Alice can even create a certification just to revoke it with a reason that's insulting. That's really just the certification-spamming abuse with frosting and sprinkles, but it's still an issue.

Summing up, you said:

> 
> I'm looking for concrete guidance that we can offer to operators of
> keystores and clients of keystores today.
> 
> Keystore operators have traditionally not wanted to be in the role of
> certificate authority, or of designated revoker (i can confirm this as a
> past and present keystore operator, but it's not just me).  They're
> looking for a reliable set of guidelines they can follow to ensure that

That's great, I agree completely. Key servers shouldn't (and likely can't) be CAs. Heck, if there's anything we know from X.509 it's that being a CA is hard. However, they can't just be a key store, if a store is a database with a web interface that allows anyone to put something into it.

A key server has to have policy that it runs. It has to solve a number of problems including abuse, but also including things like Bob being able to get rid of a key that they don't control. One of the oldest problems in the ecosystem is the new person who creates a key and then forgets their passphrase. No one yet has done the automated abuse of submitting keys for other people, but it's bound to happen, especially now that I mentioned it. Key servers need to run code to be a fair arbiter of cryptographic information.

	Jon