Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
RFC 6394

Note: This ballot was opened for revision 05 and is now closed.

(Wesley Eddy) Yes

(Stephen Farrell) Yes

(Peter Saint-Andre) Yes

Comment (2011-08-22)
No email
send info
I strongly support publication of this document.

I have one comment of substance: Section 2 states that "multiple servers ... may be co-located on a single physical host, using different ports". If I understand this statement correctly, I think the part about different ports applies to some application protocols (e.g., HTTP) but not to all application protocols. Perhaps "often using different ports" would be more accurate?

Also, it would be good to fix the minor but annoying typographical errors that have crept into the document ("ciertificate", "case a denial of service", "Section Section", etc.).

(Sean Turner) Yes

Comment (2011-08-24)
No email
send info
I'm glad that Eve's and Mallory's already precarious reputations were not further denigrated by this draft.

(Jari Arkko) No Objection

Comment (2011-08-24)
No email
send info
I would support this document with a Yes position otherwise, but I'm a bit hesitant on the ability to *replace* (not just add to) the traditional root certificate operators by DNS operators. Its not clear that I trust the DNS operators any more than I trust the root CAs... (and besides, they are often the same guys), so this flexibility seems to add potential vulnerabilities to bid down to the least trusted DNS/CA operator.


(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Adrian Farrel) No Objection

(David Harrington) No Objection

Comment (2011-08-24)
No email
send info
good draft.
multiple typos need correcting; I assume rfc editor will fix them.

(Russ Housley) No Objection

Comment (2011-08-24)
No email
send info
  Please consider the comments from the Gen-ART Review by
  Alexey Melnikov on 8-Jul-2011.

(Pete Resnick) No Objection

Comment (2011-08-24)
No email
send info
My hesitancy to put a "Yes" on this document is exactly the opposite of Jari's: I think this document bends over backwards far too much in section 3.3 to preserve traditional root CAs. Indeed, I would have much preferred if the use cases *started* with 3.3 and ended with 3.1, as I think 3.3 is the much more interesting use case. As stated in the last paragraph of 3.3, DNS ops are already trusted more than than root CAs, as a malicious DNS operator can already obtain a root CA signed cert for domains that they control, so as a domain owner I currently need to trust two entities. Better in the long run that I trust one (the DNS op), and all the better that I can be my own DNS op and be in charge of my own certs.

I am fully in favor of this effort. I only wish this document did less kowtowing to the current CA model.

(Dan Romascanu) (was Discuss) No Objection

Comment (2011-08-25)
No email
send info
Having acronyms (PKIX, AAAA, XMPP, etc. ) expanded at first occurence would increase the readability of the document 

(Robert Sparks) No Objection