Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-18

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 31 Mar 2012 20:39:56 +0000

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

This review is being undertaken early, during AD Evaluation but before IETF Last Call.  Please resolve these comments along with any other pre-Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-dane-protocol
Title: The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)
Reviewer: Murray S. Kucherawy
Review Date: March 31, 2012
IETF Last Call Date: not started
IESG Telechat Date: not scheduled

Review Summary:  This draft is almost ready for publication as an Standards Track RFC but has a few issues that should be fixed before publication.

Document Summary: The draft proposes a mechanism by which an association between a TLS certificate and an ADMD (a domain owner or similar) can be inferred from data found in the DNS.  That is, one could confirm "This key really does belong to example.com" by checking for some corresponding new data in example.com's DNS.  The goal appears to be to eliminate the current requirement for third-party certificate validation.  The document is well-formed and clearly a lot of good work has gone into it.  The IANA and Security sections are present and well-formed.  Truly, a captivating read; I was particularly moved by the authors' use of "30820454308202BC020900AB58D24E77AD2AF6300D06092A86" in Appendix C.

Major Issues (things I think the WG needs to think about, clarify, reconsider, overhaul, describe better, fret about, talk me out of, etc.):

Section 2.1.3: I don't know understand why this is a SHOULD.  Doesn't it have to match exactly?  What's an example of a situation where one could/should/would legitimately deviate from what this field says with a meaningful result?  The pseudocode in Appendix B leaves no room for SHOULD-style evaluation, so maybe this really ought to be a MUST.

Section 10: RFC1034 and RFC1035 should be normative references, probably dragged in very early in this document.  The examples in Section 2.3 rely on zone file syntax defined there, and Appendix A.2 includes quite a bit of material that requires DNS familiarity.  A reference for DNAME (I don't have it handy) would probably also be a good idea, though that one could be informative.

Minor Issues (things I believe can be improved without too much effort or additional thought):

Section 1.3: The lone MUST here seems out of place given that Section 1 is "Introduction".  I suspect it might belong in or near Section 4.  It's also unclear to me whether you're repeating a requirement of DNSSEC or declaring one imposed by the protocol this document presents.

Section 1.3: The sentence at the end of the first paragraph should probably be on its own, at the start of this section.  It should be followed by the "This document defines a secure method..." paragraph, which also has a very context-setting feel to it.

Section 2: The "TBD" here might be better replaced by a forward reference to Section 7 where that number will presumably be assigned, so that there's no need to update the same value in two places once the assignment occurs.  More on that later when I get to section 7.

Section 2.1.1: Suggest the lowercase "must" in the 0 definition be changed to "MUST".

Section 2.1.1: Suggest the lowercase "may" be changed to "can" in the 1 definition.

Section 2.2: Suggest stating that the unsigned decimal integers are eight-bit unsigned decimal integers.  (I realize this is redundant to the block diagram earlier, but since you're being so precise here, you may as well be complete.)

Section 2.3: Suggest adding an example that uses matching type 0 and selector 1.

Section 2.3: The TLSA syntax in the example has me wondering of RFC103[45] defined the space-separated integers in the zone file to do what you're obviously trying to do here.  Since I'm airborne I don't have access to confirm, but I suspect you've done your homework and this is fine.  It's just a note to me to check it when I'm back on the ground.

Section 3: Don't use active voice.  Generally, instead of "you would use", say "is used" or "would be used".

Section 4: The third paragraph is juicy insofar as I can think of other current IETF work that might be useful to reference here.  For example, might the domain name with which an association is established be useful input to the Same Origin work being done in WEBSEC?  Have they talked about this?  It might be an interesting use case to call out here or in an appendix or some such.

Section 4: The fourth paragraph needs a MUST in there somewhere, either covering the full set of steps or one for each of them.

Section 4: The third item in the bulleted list is less assertive than the other two and seems to leave things dangling a bit.  Suggest saying explicitly that the TLS session can continue but no positive assertion of an association can be made, or something like that.

Section 4, second last paragraph: In the preceding paragraph, you direct the client to consider the TLSA data unusable.  In this one, you direct the client to mark it unusable.  Is there a reason for the distinction between "considering" and "marking"?  I don't know what I would do differently here.

Section 4, last paragraph: Is this referring to a TLSA query that returns multiple answers?  I think it is; just confirming.  (You actually do answer this in the next section, I believe.)

Section 4: The last paragraph also leaves me hanging a bit.  It should probably say something about exactly what the meaning of a successful match is, since you were so clear about the meanings of the failure cases.

Section 6: Do we need version numbering in the protocol anywhere, since you're already anticipating a revision?  The answer might be "no", just want to make sure it got consideration.

Section 7.1: Why do the TBD thing instead of making the RRtype assignment request now?

Section 7.2: Would it be appropriate to make a DANE registry group for the work you're doing in 7.2, 7.3 and 7.4?  IANA might do that automatically, I suppose, but I thought I'd ask anyway.

Section 8, second last paragraph: A caveat about long TTLs meaning termination of a TLSA record can take a long time to take effect might be useful here.  (This came up in a recent SecDir review for a draft I authored in another working group.)

Section 8.1: I'm not a fan of normative language in Security Considerations.  Suggest this section be moved up to a new subsection of Section 4, or rendered non-normative.

Section A.1.2.1: Where would a naïve implementer find a guide to which algorithms are considered weak?

Section A.1.2.2: Avoid use of non-normative "should".

Appendix B: "This section is non-normative" can be removed.  There's no such thing as a normative appendix.  You didn't say it in Appendix A, so you don't need to say it here.  (One is also left wondering if Appendix A is normative with this here and not there.)

Nits (these are presentation improvements only and mostly are driven by personal preference; if you do none of these, it's fine with me, but it might save the RFC Editor some work):

Section 1.1:  s/the service that the key is used by/the service that uses the key/

Section 1.3: "DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035])" could just become "DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035]", as you did in Section 1.4.

Section 1.3: s/This document only relates to securely getting the DNS information for the certificate association using DNSSEC;/This document only relates to getting the DNS information for the certificate association securely using DNSSEC;/

Section 2.1.1: s/specifying/specifies/, otherwise the surrounding text isn't a sentence.  The fragment would be fine if this were a bulleted list or suchlike, but it reads awkwardly in this case.

Section 2.1.1: In the definition of usage type 2, there's a comma splice.  The "for example" clause should be its own sentence, e.g., "For example, a domain name administrator would use this to indicate that the domain issues its own..."
Section 2.1.2: s/specifying/specifies/, otherwise the surrounding text isn't a sentence.

Section 2.1.2: "SubjectPublicKeyInfo" isn't defined before this point.  I suspect this is likely fine; I'm doing this review on a plane without access to some of the referenced RFCs, so I just want to confirm that this isn't a dangling reference.

Section 2.1.3: s/specifying/specifies/, otherwise the surrounding text isn't a sentence.

Section 5: s/appendixes/appendices/

Section 5: s/to use TLSA records that are only shown to be validated/to use only those TLSA records that are shown to be validated/

Section 6: s/selectors type/selector types/

Section A.1: Add a comma before "care must be taken".

Section A.1.1: s/may/can/ (or "could" or "might")

Section A.1.1: Starting with the "CAs frequently reissue" paragraph, the section contains numerous grammatical errors.

Section A.1.2: s/for certificate/for a certificate/

Section A.1.2.1: s/best course...are/best course...is/, and make the bulleted list into a numbered list.

Section A.1.2.1: Should MD2 and MD5 be informative references?

Section A.1.2.2: s/not sharing key of/not sharing the key of/

Section A.2.1.3: ...or the same certificate is used for all services on a host.  (Correct?)

Section A.3: s/to securely find this out/to determine this securely/

-MSK