[openpgp] draft-dkg-openpgp-abuse-resistant-keystore-03
Phil Pennock <ietf-phil-openpgp@spodhuis.org> Thu, 25 April 2019 08:35 UTC
Return-Path: <ietf-phil-openpgp@spodhuis.org>
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 B35E5120111 for <openpgp@ietfa.amsl.com>; Thu, 25 Apr 2019 01:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=jKo1KZ/z; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=JzDJpUy7
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 KR9tZtyMV_W0 for <openpgp@ietfa.amsl.com>; Thu, 25 Apr 2019 01:35:39 -0700 (PDT)
Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4671200E5 for <openpgp@ietf.org>; Thu, 25 Apr 2019 01:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902; h=Content-Type:MIME-Version:Message-ID:Subject:Cc: To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AH66/lRhjmroWWKMnK83s8HIBPqG3XoIIzwNNG71N9Q=; b=jKo1KZ/ziF9LcF4kxq7JSwaf3L MLmfrnKQHvoDGkS0zxrNuF/pCyRkM54GFHN/PSIzltJyKtoUxVAlwWFzvZxb0rHqbLlcVKjizlnNC 5Y9A6xJCvxebpvszRkxGuTkZZwADj06cGhki24kQ7vdhy5u5VSKJNBql16G6gwtk9vVLNIOlmB6T5 5gqdhWZf99Yb9ByWXOqPfDmcnpro3yH8wIORWhLYoQoYlnGWB4khZVo8XWk5IHsXPUZrSpc/j3ZPc UIM3a4VJ2wwxMSoPRm/WnWKA+MMgDgoO436wqibca8W00M5zl4o5AcCHpiv3Bxec/KZ0gt7vLo8hy joZ7K1+w==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201902e2; h=Content-Type:MIME-Version:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AH66/lRhjmroWWKMnK83s8HIBPqG3XoIIzwNNG71N9Q=; b=JzDJpUy7+J8krwJwdbLAZ29dE3 1xwJNQ4yLJPF4y+1x9zpOXZOAJ2AEMS4t8bLPqaESR/6ACDLp3xD4TKwhVDQ==;
Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) id 1hJZqw-000IIv-JP; Thu, 25 Apr 2019 08:35:34 +0000
Date: Thu, 25 Apr 2019 01:35:31 -0700
From: Phil Pennock <ietf-phil-openpgp@spodhuis.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: openpgp@ietf.org
Message-ID: <20190425083528.GA16784@breadbox.private.spodhuis.org>
Mail-Followup-To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/TM2fReuXOHEaGma5q5J8CZToxCo>
Subject: [openpgp] draft-dkg-openpgp-abuse-resistant-keystore-03
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: Thu, 25 Apr 2019 08:35:43 -0000
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~`*&^$#_-={}'?b@spodhuis.org 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
- [openpgp] draft-dkg-openpgp-abuse-resistant-keyst… Phil Pennock