[apps-discuss] AppsDir review of draft-ietf-dane-protocol-14
Barry Leiba <barryleiba@computer.org> Mon, 23 January 2012 01:05 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED8B21F85E9 for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 17:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.866
X-Spam-Level:
X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3if9i7CgXTy for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 17:05:41 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A79C921F85E4 for <apps-discuss@ietf.org>; Sun, 22 Jan 2012 17:05:41 -0800 (PST)
Received: by obbwc12 with SMTP id wc12so2964183obb.31 for <apps-discuss@ietf.org>; Sun, 22 Jan 2012 17:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=zHE/ZBxBzYPDmxx+mmU2yAgKmg4HfT0b5+cZ4dxdlV0=; b=NpW/llCrmbYPihw87nRJBpDDSNRI333hPpLLgrzYW4uV5jsblqbgqBj/wefWhupxis awSXr7YnJKBNAx4lSBpVSCdExhe47ZDRRn0gsEPkOOBlbON2pBqYqUAbYHYU7cXLlOa9 PGHAIxEayUGoOQ4Vq5YHSus+NdhAtLswNPBrw=
MIME-Version: 1.0
Received: by 10.182.47.10 with SMTP id z10mr6145848obm.19.1327280739980; Sun, 22 Jan 2012 17:05:39 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.60.55.137 with HTTP; Sun, 22 Jan 2012 17:05:39 -0800 (PST)
Date: Sun, 22 Jan 2012 20:05:39 -0500
X-Google-Sender-Auth: cmidUsytsJiHPJhdUY-mfleSCO0
Message-ID: <CALaySJL46XM0nzxpOsxQKFvMHKC-nfR5jz3P4eZv-YKG3+0Z2A@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: apps-discuss@ietf.org, draft-ietf-dane-protocol.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jan 2012 01:05:45 -0000
An Applications Area Directorate review has been requested for draft-ietf-dane-protocol-14, and I have been selected as the reviewer (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Summary: The protocol appears solid and useful, and the document does not seem to have any major issues. I have some comments below, a few substantive but most editorial. I've marked the substantive ones (and the editorial ones that I think significantly affect the understanding of the document) with "SUBSTANTIVE". -------------- Section 1.2 OLD DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital Trivial, but I think it will read better this way: NEW DNSSEC [RFC4033] [RFC4034] [RFC4035] uses cryptographic keys and digital OLD Information retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. The non-parallel construction of the first two clauses made me read this too many times before I could parse it. NEW Information that is retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. -------------- Section 2.1.1 OLD This will be an IANA registry in order to make it easier to add additional certificate usages in the future. NEW This value is defined in a new IANA registry [see sec 7.2] in order to make it easier to add additional certificate usages in the future. I also suggest adding section references in sections 2.1.2 and 2.1.3, to the other two IANA registries. OLD formats for certificates, those certificates will need their own certificate types. NEW formats for certificates, those certificates will need their own certificate usage values. -------------- Section 2.1.3 SUBSTANTIVE OLD Using the same hash algorithm as is used in the signature in the certificate will make it more likely that the TLS client will understand this TLSA data. I think I know what this is meant to say, but I had to work too hard for it to become clear. Maybe this?: NEW Because a client support for multiple hash algorithms might be limited, it is advisable to use the same hash algorithm for the matching type as is used for the signature in the certificate. Doing so will increase the likelihood of interoperability. -------------- Section 2.1.4 SUBSTANTIVE OLD The "association data" to be matched. The field contains the bytes to be matched or the hash of the bytes to be matched. The source of the data to be matched is controlled by the Matching Type field. It's definitely NOT the "hash of the bytes to be matched", right? The hash *is* the set of bytes to be matched. I know what you're trying to say, but this seems an imprecise way to say it. Maybe this?: NEW The "association data" to be matched. The field contains the bytes to be matched -- the raw data, for matching type 0, or the hash of the raw data, for matching types 1 and 2. -------------- Section 2.3 SUBSTANTIVE The first example has an opening parenthesis after "IN TLSA"; the second and third don't. -------------- Section 3 SUBSTANTIVE 2. The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", "udp" and "sctp". Should there be a registry for these, as well? -------------- Section 4.1 OLD Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that the must be found in any of the PKIX validation chains Spurious "the". NEW Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that must be found in any of the PKIX validation chains -------------- Section 4.4 OLD Some specifications such at [RFC6125] detail how to match the identify given in a PKIX certificate with those expected by the user. Two typos here: "such at" and "identify". NEW Some specifications such as [RFC6125] detail how to match the identity given in a PKIX certificate with those expected by the user. OLD o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. Non-parallelism. NEW o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. ...or, alternatively, remove "to cause" entirely. I prefer changing "to" to "MUST"; the repetition is more clear, I think. OLD Clients that validate the DNSSEC signatures themselves MUST either use standard DNSSEC validation procedures or a secure transport (such Misplaced "either". NEW Clients that validate the DNSSEC signatures themselves MUST use either standard DNSSEC validation procedures or a secure transport (such Moreover, I find that the parenthesized list separates the "MUST use secure transport" from "between A and B" with too much, making it easy to lose the message. Maybe this?: SUBSTANTIVE NEW NEW Clients that validate the DNSSEC signatures themselves MUST use either standard DNSSEC validation procedures or a secure transport between themselves and the entity performing the DNSSEC signature validation. Examples of such secure transport are TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. -------------- Section 5 The different types of certificates for association defined in TLSA are matched with various sections of [DANEUSECASES]. The three use cases from section 3 of [DANEUSECASES] are covered in this protocol as follows: There are four use cases in DANEUSECASES; you don't mention 3.4 Delegated Services. Is that an oversight, or should you say, "Three of the use cases ..." ? (note that some of these might be excessively glib) That seems like an odd thing to say in a completed document, so I presume you'll either decide to say more or take that parenthesized statement out. For my part, I think what's there now is fine. -------------- Section 6 OLD A system creating TLSA records that conforms to this specification MUST be able to create TLSA records containing certificate usages 0, 1 and 2. A system creating TLSA records that conforms to this specification MUST be able to create TLSA records with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo). A system creating TLSA records that conforms to this specification MUST be able to create TLSA records using matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to create TLSA records using matching type 2 (SHA-512). Here, the repetition seems clumsy, heavy. May I suggest this?: NEW A system creating TLSA records that conforms to this specification MUST be able to create TLSA records o containing certificate usages 0, 1 and 2, o with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo), and o using matching type 0 (no hash used) and matching type 1 (SHA-256). In addition, the system SHOULD be able to create TLSA records using matching type 2 (SHA-512). Similarly, I suggest this for the next paragraph: NEW NEXT A TLS client conforming to this specification MUST be able to o correctly interpret TLSA records with certificate usages 0, 1 and 2, o compare a certificate for association with a certificate from TLS using selectors type 0 and 1, o compare a certificate for association with a certificate from TLS using matching type 0 (no hash used) and matching type 1 (SHA-256). In addition, the client SHOULD be able to make such comparisons using matching type 2 (SHA-512). -------------- Section 7.2 SUBSTANTIVE This document creates a new registry, "Certificate Usages for TLSA Resource Records". The registry policy is "RFC Required". Have a look at http://tools.ietf.org/html/draft-leiba-iana-policy-update and you'll see where this comment is coming from. RFC Required might be the right choice for this registry, and the fact that you're using Specification Required for the other registries makes me confident that you've thought about it and chosen for a good reason. I'd like to see the reason(s) documented here. Something like, 'The registry policy is "RFC Required" because community review of this parameter is necessary to ensure [blah-blah].' Reasonable? -------------- Section 7.3 The other two registry definitions say: Applications to the registry can request specific values that have yet to be assigned. ...and this one doesn't. I presume it should for consistency. Or is there something else here? -------------- Section 8 SUBSTANTIVE The client, seeing the proxy's new certificate for the supposed destination will not set up a TLS session. Thus, such proxies might choose to aggressively block TLSA requests and/or responses. Having not been in on the discussions about this, I'm not sure whether this is (1) advice to SSL proxies, (2) a warning to intended hosts, or (3) a warning to clients. If (1), I'm also not sure how it would do the blocking, and whether something should be said about that here. If (2) or (3), I'm also not sure what, if anything, they should be advised to do about the situation. -------------- Appendix A I started to correct errors here, but then found that there are *so* many typos, missing "the", number disagreements, and other grammatical errors in the appendix that I just have to suggest to Paul that you go through it and fix them -- I'm sure they're a result of non-native English writing. The RFC Editor will eventually fix what's left, but we should do our best first. -------------- Barry
- [apps-discuss] AppsDir review of draft-ietf-dane-… Barry Leiba
- Re: [apps-discuss] AppsDir review of draft-ietf-d… Barry Leiba