Re: [openpgp] The DANE draft
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 05 August 2015 04:02 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980C51B2BD8 for <openpgp@ietfa.amsl.com>; Tue, 4 Aug 2015 21:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
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 3BsF141kWg_V for <openpgp@ietfa.amsl.com>; Tue, 4 Aug 2015 21:02:01 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCEA1B2BD2 for <openpgp@ietf.org>; Tue, 4 Aug 2015 21:02:01 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 68E01F984; Wed, 5 Aug 2015 00:01:58 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id B7FCA1FF70; Wed, 5 Aug 2015 06:01:48 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Paul Wouters <paul@nohats.ca>, IETF OpenPGP <openpgp@ietf.org>
In-Reply-To: <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca>
References: <CAMm+LwhYdBLXM8Td8q8SCnzgwywRgMx3wNKeS_Q0JSN4Lh7rZQ@mail.gmail.com> <87bnf1hair.fsf@alice.fifthhorseman.net> <alpine.LFD.2.11.1507250832510.854@bofh.nohats.ca>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 05 Aug 2015 00:01:45 -0400
Message-ID: <87bnem2xjq.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/SFiB40WqM-nddN2KClCbl6bwYdU>
Subject: Re: [openpgp] The DANE draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 05 Aug 2015 04:02:04 -0000
On Sat 2015-07-25 08:56:09 -0400, Paul Wouters wrote: > [ dkg wrote: ] >> I looked at it with Petr Spacek after the meeting, and i plan on >> providing Paul with a more detailed review shortly. > > Greatly appreciated! heh, fsvo "shortly" :/ i'm not subscribed to dane@ietf.org, feel free to forward if you think this would be useful. key discovery vs key validation ------------------------------- As an optional key discovery mechanism for OpenPGP, i think this proposal has merit. I share Watson's concerns about "smuggling in a different trust model", but i have no complaints about DNSSEC validation being used as a corroborative validation mechanism, should clients choose to accept it for validation purposes. For clients that *don't* choose to accept it for validation purposes, they should validate the keys via their usual mechanisms, and rely on OPENPGPKEY records solely for discovery purposes. metadata leakage ---------------- I'm a little concerned about the potential for metadata leakage -- i don't want my MUAs to do DNS lookups every time i try to send mail to someone whose keys i dont have. Until DPRIVE is a reality (and maybe even after that) the DNS leaks much more information than my typical MUA -> MSA connection. (i like the metadata channel minimization offered by draft-moore-smtp-addrquery for that reason). localpart mangling ------------------ I have no strong preference for base32 vs. digested localpart for the hostname. Digested localparts require a little bit more work to invert than base32, but given the low entropy of typical normalized localparts, they don't provide a lot of protection against a determined attacker. I'm slightly more concerned with e-mail address length limits on base32 than on digested localparts -- a long localpart plus a long domain name could make for a very large DNS label, whereas a fixed digest should give us a fixed bound on size. In either case, some canonicalization will be required (before base32 or digest, whichever is chosen). fwiw, i believe that case normalization of the localpart is pragmatic for today's networks, despite not being within the letter of the RFC. I would advise clients to downcase before doing a lookup. The main advantage for base32 over digested localpart seems to be for synthesized OPENPGPKEY records in an online-signing DNSSEC-capable server. I don't believe this is a significant advantage for a key discovery mechanism for OpenPGP, because i believe some people will want to verify the OpenPGP certificate itself, regardless of its DNSSEC status, and the OpenPGP certificate won't have wildcards in it. RDATA content/structure ----------------------- The -03 spec §2.1 currently suggests that the RDATA should be an "RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public keyring" in any reusable way (see https://tools.ietf.org/html/rfc4880#section-3.6). § 2.2 says: The RDATA Wire Format consists of a single OpenPGP public key as defined in Section 5.5.1.1 of [RFC4880]. Note that this format is without ASCII armor or base64 encoding. But 5.5.1.1 is *just* a public key packet. This is not a useful record to store. Instead what you want is probably exactly one "Transferable Public Key" (https://tools.ietf.org/html/rfc4880#section-11.1), which is the standard for the composable OpenPGP certificate format. But see the "Filtered Certificates" section below for more detail. Key Transitions --------------- While i say "exactly one" Transferable Public Key, i'm assuming that the DNS is OK with serving multiple OPENPGPKEY records at a single label. This would be necessary for people to be able to handle a key transition. Some examples are: 0) Alice makes a new stronger primary key that she wants people to know about, while she continues to use her older, better-known key for several months. 1) Bob makes a new primary key using a new key algorithm (e.g. ECC) that he knows won't be universally supported. He publishes it alongside his more traditional (e.g. RSA) key. 2) Carol's longstanding key has been compromised. She revokes it, makes a new key, and wants to publish both the revoked certificate as well as her new cert. I think all of these cases can be served by multiple OPENPGPKEY records. Filtered Certificates --------------------- Given that some users have aggregated OpenPGP certificates that are quite large (my own is currently ~475KB), we don't want to require people to publish their entire certificate in the DNS. Because OpenPGP certificates ("transferable public keys) are composable (they consist of a series of packets, many of which can be dropped), a reasonable policy for filtering the certificate for size purposes should be suggested. At a minimum, the OPENPGPKEY record for alice@example.com MUST contain: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding X to Y. [ note: I do not believe we need to require that the User ID MUST match the looked-up record, though it's obviously preferable to a validator if it does. ] This extremely minimal record might not provide an encryption-capable subkey, though, and the primary key may not be encryption-capable itself. So a more sensible transferable public key would also include all relevant subkeys: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding Y to X. - encryption-capable subkey Z - self-signature from X, binding Z to X. - [ other subkeys if relevant ...] Owners of the record may also want to include some up-to-date third-party certifications which they think would be helpful for validation, which would result in: * primary key X - one User ID Y, SHOULD match 'alice@example.com' - self-signature from X, binding Y to X. - third-party certification from V, binding Y to X - [ other third-party certifications if relevant ...] - encryption-capable subkey Z - self-signature from X, binding Z to X. - [ other subkeys if relevant ...] So when preparing these records for a specific OPENPGPKEYDATA with the goal of minimizing certificate size, a normal user would normally want to: 0) where one User ID from their cert matches the looked-up address, strip away non-matching User IDs and any certifications (self-sigs or third-party certs) associated with them 1) strip away all User Attribute packets and associated certifications 2) strip away all expired subkeys (may want to keep revoked subkeys if they were revoked prior to their preferred expiration to ensure that correspondents know they are properly revoked) 3) strip away all but the most recent self-sig for the remaining user IDs and subkeys 4) (optionally) strip away any uninteresting/unimportant third-party User ID certifications. This is a value judgement that will be made imperfectly, since the person creating the record doesn't know the trust model of the recipient. At the very least, the RDATA owner should strip all third-party ceritifcations which have been superceded by other certifications from the same third-party, as well as any expired third-party certs. Other useful filtering rules might include the date of the third-party cert (recent certs are better), strength of the third-party cert (stronger keys are better), the size of the third-party cert (smaller certs are better), "connectedness" of the third-party making the cert (e.g. based on some measurement of presence in the WoT strong set), or some domain-specific policy (e.g. always include third-party certs from the organization's internal CA key) With GnuPG, you can achieve a rough minimization with: gpg --export-options export-minimal,no-export-attributes $PGPFPR > opengpgpkey.pgp (this still exports expired subkeys and alternate User IDs, so further filtering could be done to make the record even smaller) Applying the most extreme of these minimization rules (with no third-party certifications whatever) my own OpenPGP certificate (with a single large primary key, a relatively long User ID, and three large subkeys) is < 4KiB. For even the largest ECC keys (nistp521) with a cert with distinct primary key and subkey, the filtered/minimized cert is well below 1KiB. does this make sense? I'm happy to discuss it further. Regards, --dkg
- [openpgp] The DANE draft Phillip Hallam-Baker
- Re: [openpgp] The DANE draft Werner Koch
- Re: [openpgp] The DANE draft Stephen Farrell
- Re: [openpgp] The DANE draft Aaron Zauner
- Re: [openpgp] The DANE draft Aaron Zauner
- Re: [openpgp] The DANE draft Stephen Farrell
- Re: [openpgp] The DANE draft Daniel Kahn Gillmor
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] The DANE draft Phillip Hallam-Baker
- Re: [openpgp] The DANE draft Phillip Hallam-Baker
- Re: [openpgp] The DANE draft Phillip Hallam-Baker
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Paul Wouters
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] The DANE draft Watson Ladd
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Werner Koch
- Re: [openpgp] The DANE draft Werner Koch
- Re: [openpgp] The DANE draft Olafur Gudmundsson
- Re: [openpgp] The DANE draft Simon Josefsson
- Re: [openpgp] The DANE draft Daniel Kahn Gillmor
- Re: [openpgp] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Stephen Farrell
- Re: [openpgp] [dane] The DANE draft Stephen Farrell
- Re: [openpgp] [dane] The DANE draft Paul Hoffman
- Re: [openpgp] [dane] The DANE draft Paul Hoffman
- Re: [openpgp] The DANE draft Daniel Kahn Gillmor
- Re: [openpgp] [dane] The DANE draft Daniel Kahn Gillmor
- Re: [openpgp] [dane] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Hosnieh Rafiee
- Re: [openpgp] [dane] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Hosnieh Rafiee
- Re: [openpgp] [dane] The DANE draft Hosnieh Rafiee
- Re: [openpgp] [dane] The DANE draft Vincent Breitmoser
- Re: [openpgp] [dane] The DANE draft Stephen Farrell
- Re: [openpgp] [dane] The DANE draft Paul Wouters
- Re: [openpgp] [dane] The DANE draft Jiankang Yao
- Re: [openpgp] [dane] The DANE draft Daniel Kahn Gillmor