Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
draft-ietf-dane-use-cases-05
Yes
(Stephen Farrell)
(Wesley Eddy)
No Objection
(Adrian Farrel)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
Note: This ballot was opened for revision 05 and is now closed.
Peter Saint-Andre Former IESG member
Yes
Yes
(2011-08-22)
Unknown
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 Former IESG member
Yes
Yes
(2011-08-24)
Unknown
I'm glad that Eve's and Mallory's already precarious reputations were not further denigrated by this draft.
Stephen Farrell Former IESG member
Yes
Yes
()
Unknown
Wesley Eddy Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2011-08-25)
Unknown
Having acronyms (PKIX, AAAA, XMPP, etc. ) expanded at first occurence would increase the readability of the document
David Harrington Former IESG member
No Objection
No Objection
(2011-08-24)
Unknown
good draft. multiple typos need correcting; I assume rfc editor will fix them.
Jari Arkko Former IESG member
No Objection
No Objection
(2011-08-24)
Unknown
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.
Pete Resnick Former IESG member
No Objection
No Objection
(2011-08-24)
Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-08-24)
Unknown
Please consider the comments from the Gen-ART Review by Alexey Melnikov on 8-Jul-2011.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown