Re: dane-openpgp 2nd LC resolution
Paul Wouters <paul@nohats.ca> Mon, 14 March 2016 23:18 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02012D7E2 for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 16:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no
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 zc4zCzluPoOM for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 16:18:33 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6664812D7BD for <ietf@ietf.org>; Mon, 14 Mar 2016 16:18:33 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qPDFf0Nl9z1jQ; Tue, 15 Mar 2016 00:18:30 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pU-_DqhByNKt; Tue, 15 Mar 2016 00:18:24 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Mar 2016 00:18:23 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 29EED603BBA1; Mon, 14 Mar 2016 19:18:22 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 29EED603BBA1
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 252E9A3C7; Mon, 14 Mar 2016 19:18:22 -0400 (EDT)
Date: Mon, 14 Mar 2016 19:18:22 -0400
From: Paul Wouters <paul@nohats.ca>
To: Doug Barton <dougb@dougbarton.us>
Subject: Re: dane-openpgp 2nd LC resolution
In-Reply-To: <56E636FD.9050902@dougbarton.us>
Message-ID: <alpine.LFD.2.20.1603141916360.830@bofh.nohats.ca>
References: <56DC484F.7010607@cs.tcd.ie> <56E636FD.9050902@dougbarton.us>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UupLYkabrPttdO98SbpYbtLteoQ>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2016 23:18:36 -0000
On Sun, 13 Mar 2016, Doug Barton wrote: Hi Doug, > Date: Sun, 13 Mar 2016 23:58:53 > From: Doug Barton <dougb@dougbarton.us> > To: ietf@ietf.org > Subject: Re: dane-openpgp 2nd LC resolution > In general I support the idea of an *experimental* draft on this topic. Thanks. > However, I have some serious concerns about the suggested approach. I > realize that I'm late to the party on this, so I apologize in advance to > Paul. I've subscribed to the DANE WG ML so hopefully I can make a more > useful contribution going forward. (FWIW, the last time I checked the > suggested approach was one I agreed with, so I diverted my attention to > more personally critical pursuits.) Yes, you are about 1.5 years late. And your arguments are (un)fortunately not new arguments. Since the archive on this draft is rather huge, I can understand that you missed part of this discussion. So for completeness sake, I will answer your questions again. > Fundamentally I think that using this RR to return the cert itself is > the wrong approach. IMO it should return the full fingerprint of the key > and let the sending user retrieve the key itself, with all corresponding > material. This argument has come up a number of times, and it has been rejected each time. > This overcomes several problems I see with the proposal: > > 1. We know from vast experience with PGP that users are very lazy about > updating keys, and everything associated with them. I don't see how that differs from where they need to update the key from/to. > 2. The draft recommends that the version of the key that is published be > stripped of any "extraneous" material such as unrelated UIDs, photos, > various certifications, etc. Given the desire to keep the packet size as > small as possible these recommendations are sensible, but I question > whether the resulting certificate has sufficient utility. Leaving some signatures on it to anchor it in the web of trust is fine. What is meant is to strip away the photo, and other non-required items. The problem is not really of "big keys", which we handle fine in DNSSEC (see below) but there is an upper limit of 64k in DNS that you must remain under. So having 100s of signatures and a photo is not going to fit. It does not matter whether the key is 2k, 12k or 63k. > One could also > argue that most users think of "my PGP key" as the entire package of the > main key, along with the the various associated UIDs, subkeys, etc. That's fine. See above. > 3. Encryption subkeys are not tied to specific UIDs. Also, it's not at > all clear to me how the mechanism described in this draft would interact > with a "key" that has multiple encryption subkeys. I don't see why the draft needs to say anything about that? How is that different from obtaining this key via another transport like HKP ? > 4. The draft suggests (primarily in Section 7.1) that this mechanism be > utilized in a side channel (my term) separate from the sending user's > existing keyring(s). I do not understand what you mean here. > I have deep concerns about this approach, as it > increases the risk that a message could be sent encrypted to the wrong > key. The biggest risk in this case is that of a false positive, where > the sending user believes that the message was correctly encrypted. This draft on purpose provides no GUI to the user. As it states clearly, this is not a replacement for the Web Of Trust. > That's arguably still better than the alternative of sending the same > message unencrypted. Not "arguably". There is nothing to argue about it. It _IS_ better than sending it plaintext - if you do not mislead the sender by any "security" claims in the GUI. > However it's not better than the alternative of > informing the user that the MTA was not able to send the message because > it couldn't find a key that it could rely on. Hard fail is certainly possible as a local policy, and everyone is free to implement that. It is not up to the draft to dictate either hard fail or soft fail. This is identical to TLS soft/hard fail which is a browser matter, and not a TLS protocol matter. Local policy might be different based on whether there is a direct link to the enduser (MUA) or not (MTA) > 5. Super large OPENPGPKEY RRs will undoubtedly be used as DDOS > amplification fodder. For example, using Paul's software to generate the > RR for my primary key/UID the resulting packet would be over 12k. The draft is very clear about how to avoid amplification. It is not supposed to respond on non-source verified transport, such as plain UDP. It should be used with TCP or UDP with DNS COOKIES for this very reason. > All 5 of these issues are resolved by having the OPENPGPKEY RR specify > the signature of the key, and having the sending user's software deal > with the full key instead of only a truncated version. But it introduces a complexity of third party PKI systems on top of DNSSEC and/or direct unfiltered/uncensored communucation to this third party service. If you point to an HTTPS server, then one needs to take that trust model with PKIX/CAs into account. What do you do when the TLS certificate is expired? Or from a bad CA? Or when you just don't receive an answer to your first TCP packet because the attacker is on-path and filtering you to attempt to lure you into sending it in the clear? Or when it is an SMTP extension but your ISP blocks all SMTP communication to non-ISP SMTP servers. The strength of this document lies in the fact that it does not depend on third party services. DNSSEC provides the Indeterminate and Bogus status, so you know when an attack is happening. Adding third parties to that destroys this property which is essential. > 1. To the extent that users are likely to update anything with their > key, they are likely to send a current version to the key servers. The key servers are the equivalent of the Great Garbage Patch of the internet. It is full of expired keys, lost keys, mallicious keys and fake keys. These servers are also closely monitored and/or attacked by nationa states, etc etc. It provides a simple central point of failure. The strength of DNS is that it is a distributed system with intermediary caches. > Further, in the case of a key revocation (particularly for a compromised > key), it may not be possible to remove or modify the OPENPGPKEY RR in a > timely manner, or at all. A good implementation would use reasonable TTL's and provide a decent GUI for inserting, updating and deleting the DNS record. This is not worse then a website needing to update their A record. We are not saying A records are bad because a website cannot update their A records in a timely matter. So I find this argument a bit of a straw man. > However the receiving user should be able to > upload a revocation cert for the key to the key servers, which would be > picked up by sending user's software. Realistically, the real problem is losing the key to be able to revoke it. With DNS, you can just stop publishing that key. So it is in fact much better than a third party append-only store like current pgp key servers. > 2. Having the sending user's software retrieve the full key gives them > the most up to date version, and matches better with what I believe the > expectations of most users would be for this RR. Email software doing so can do that from alternative locations if desired. It does not need to be in the core functionality of this draft. Especially for security reasons I mentioned earlier. > 3. Retrieving the whole key puts the problem of multiple encryption > subkeys into the hands of the sending user's software, where there are > already well known solutions. You can publish as much of the key as you need to get the equivalent. The draft is fine with keys up to 63k. > 4. The way that this mechanism interacts with the user's existing key > ring still needs more thought. That is really local policy and we have given some guidelines on it. Anything more specific runs into infinite discussions about what the protocol should dictate and where people want local policy to apply. > Regarding 4, I see several likely scenarios: > > 1. The user already has exactly 1 key that contains exactly 1 UID which > matches the e-mail address: > - The OPENPGPKEY result matches: The user is notified, the user's > software MAY make note of this match and suitably increase the "validity > score" for the key (if the software has such a concept) > - The OPENPGPKEY result does not match: The user is notified, MTAs/MUAs > SHOULD halt processing at this point, and let the user manually rectify > the error. User's software MAY make note of the mismatch and suitably > decrease the "validity score" for the key (if the software has such a > concept) It would depend. Currently we state the local key ring always trumps the policy, so if the user manually put trust in that key it should use that key instead. If MAY inform the user if a mismatch occurs. It MAY decide to use the new key if it is signed by the locally stored manually trusted key. All of this is really local policy and it will take another 10 years to get any kind of consensus on trying to write this down as a protocol specification. > 2. The user has more than one key, and/or more than one UID which > matches the e-mail address: > - There is an RR which corresponds to one of the known keys: See the > first mechanism under 1 above. > - Otherwise see the second mechanism under 1 above. Additionally, the > software MAY ask the user if they would like to download the key that > matches the RR for evaluation. I don't see how this draft prevents you from doing so. If you have a local key that is manually verified, it and the user local policy trumps and an implementation MAY decide to warn to user instead of using either old or new key. > 3. The user has no extant keys which match the e-mail address: > - There is an RR which corresponds: The software MAY ask the user if > they would like to download the key that matches the RR for evaluation. > - There is not, the user is notified, and the software MAY suggest that > the user search the key servers. I would not want to specify that users should go to search existing key servers. See above :P All of this is local policy and none of us should attempt to dictate that. > The draft currently suggests a mechanism for using the RR data in an > unattended manner. I believe that this is a mistake for an experimental > draft, and should be replaced with text which makes it clear that at > this stage of the experiment the software SHOULD NOT proceed without > user confirmation. That destroys opportunistic encryption for no good reason and I'm FIRMLY against any proposal for that. Encrypted to OPENPGPKEY without informing the user of "additional security" is ALWAYS better than sending in the clear, which is the situation we have today. Manual key verification has failed and is the main reason most of our emails are not end-to-end encrypted as it is. Your suggestion of bringing back the user before using a key to encrypt basically adds nothing to today's failed state of mostly unencrypted emails being sent. > Some other thoughts: > > The draft needs to be even more clear about its intentions. Specifically > it needs to spell out how the mechanism should be used. I see two > scenarios, but that doesn't mean there are only two: > > 1. This mechanism can be used as a data point in the WOT > 2. This mechanism can be used for opportunistic encryption > > Personally I don't see anything wrong with #2, but the sending user has > to be involved in the decision-making process. Retrieving the full key > will make that user's decision making process easier. I've answered above already why I think this is wrong. > I would like to see more explanation of the mechanism for representing > the local part. I think that the explanation of "Why do we need to hash > it?" is good, however it's not clear to me why SHA-256 was chosen, or > why the hash value is truncated the way that it is. I don't see why that information needs to be in the draft. SHA-256 was chosen over SHA-224 and SHA-1 because: 1) SHA1 is being removed from libraries and/or is disallowed in FIPS mode. 2) SHA2-224 is not part of the Microsoft Crypto library. 3) SHA2-256 does not suffer from 1) or 2) and we need to be < 63 octets. > Obviously a full 64 > character hex encoding of a SHA-256 hash would overflow the 63 byte > limit for a single DNS label. But why truncate the value specifically to > 28 octets? If the 63 byte limit is the concern, why not use SHA-224? Microsoft :P > I'd also like to suggest an alternative mechanism for this problem. In > cases where the entire local part of the address consists exclusively of > 1-63 Letter-Digit-Hyphen (LDH) characters, allow that representation to > be used directly. > That would greatly simplify provisioning in the common > case, and also go part of the way towards addressing John Levine's > concern about the poor DNS admin who needs to go in and clean up those > records later. (That said, the records themselves refer to a key which > will answer said admin's question, so while it's a bit of extra work the > hash doesn't make answering the question impossible.) That leads to maybe requiring multiple queries, and additionally it was pointed out that it makes it easier for DNS servers to log the usernames. yes hashing is not irreversable, especially for predictable and published names, but people believed the additional privacy was still worth it. And the reason for hashing the local-part and not the entire email address is to allow users to use CNAME/DNAMEs) without needing to create OPENPGPKEY records per zone. > This would also require a bit of text warning mail/DNS admins to mandate > hashes in the event that local delivery is case sensitive, but I really > think that this is such a corner case (again, pun intended) as to be > nearly a non-issue. Yes, this non-issue has generated the majority of emails and delays, so I am very reluctant to make any further changes and re-ignite this discussion as people simply have different opinions that are unchanging. > In cases where the local part contains a non-LDH character, the hashing > mechanism is mandatory. Obviously the system should fall back to trying > the hash version of the RR for a "simple" local part as described above. If we cannot even decide on when we can lowercase() I really don't want to talk about which characters are "legal" and can do without hashing, and which cannot. But regardless, the privacy issues with DNS resolver intermediaries also makes hashing a requirement, even for US-ASCII. > Given that the draft specifies a new RR with its own ID, there is no > need for the _openpgpkey intermediate label. A query such as 'dig > doug.barton.us openpgpkey' would do the right thing (once all the > software catches up to the eventual RFC of course). The subzone allows a separate DNS server to act as a DNS keyserver. For instance, when we populated the fedoraproject.org zone with a couple of thousand keys, the size of the zonefile was big enough to cause problems, and it is nice to be able to store and serve it as a separate zone on possibly a separate machine. > I would avoid using 'LHS' to refer to the local part of the e-mail > address in order to avoid confusion with the way that acronym is > commonly used in reference to DNS RRs. The draft uses local-part everywhere. The term "LHS" appears once: If one of the OpenPGP key uids contains only a single wildcard as the LHS of the email address, such as "*@example.com", the OpenPGP public And it refers to using "*" as the LHS. It is not a local-part of an email address. > The discussion about local part wildcards in 5.3 confuses me. How would > the user know how to hash the wildcard to look up the RR, given a real > e-mail address as the starting point? A wildcard would match any hashed attempt. the user does not need to know anything and can just hash its intended local-part. > The details on how the sending user's software should use the returned > data should be moved out of Section 7 (Security Considerations) and into > Section 5. Also, see above. :) > > If we stick with sending the whole cert back in the RR the Security > Considerations section should list use of such answers in DDOS > amplification attacks as a risk. You think 7.4 in the Security Considerations is not enough? 7.4. Response size To prevent amplification attacks, an Authoritative DNS server MAY wish to prevent returning OPENPGPKEY records over UDP unless the source IP address has been confirmed with [EDNS-COOKIE]. Such servers MUST NOT return REFUSED, but answer the query with an empty Answer Section and the truncation flag set ("TC=1"). Paul
- dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution E Taylor
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Treat model (was: Re: dane-openpgp 2nd LC resolut… John C Klensin
- Case distinctions as theoretical exercise (was: R… John C Klensin
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution John Levine
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise Doug Barton
- Re: Threat model Doug Barton
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise John C Klensin
- Re: dane-openpgp 2nd LC resolution John R Levine
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Mark Andrews
- Re: dane-openpgp 2nd LC resolution Warren Kumari
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: Case distinctions as theoretical exercise John Levine
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Hashing local-parts of addresses (was: dane-openp… ned+ietf