The IESG has approved the following document: - 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' (draft-ietf-dane-use-cases-05.txt) as an Informational RFC This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ Technical Summary Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The DANE WG has been asked at the IETF80 meeting in Prague to write the use cases document before it continue the work on the DANE protocol draft. The draft has been discussed in the DANE WG mailing list and has a strong consensus in the WG for publication as an informational RFC with notable exception of controversy about allowing to use DNS responses not validated by DNSSEC in one of the use cases. The rough consensus is that this is still a valid use case and the issue will be addressed and resolved in the DANE protocol draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document was reviewed by various people and has been through WGLC successfully. Personnel Ond?ej Surý (ondrej.sury@nic.cz) is the Document Shepherd. Stephen Farrell (stephen.farrell@cs.tcd.ie) is the responsible AD. RFC Editor Note 1. Section 1, last para on p3. s/holder/operator/ OLD: " With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit. " NEW: " With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain operator and not tampered with in transit. " 2. Add this text at the end of Section 2 NEW: " This document refers several times to the notion of a "domain holder". This term is understood to mean the entity that is authorized to control the contents of a particular zone. For example, the registrants of 2nd- or 3rd-level domains are the holders of those domains. The holder of a particular domain is not necessarily the entity that operates the zone. It should be noted that the presence of a valid DNSSEC signature in a DNS reply does not necessarily imply that the records protected by that signature were authorized by the domain holder. The distinction between the holder of a domain and the operator of the corresponding zone has several security implications, which are discussed in the individual use cases below. " 3. Section 2, 2nd para - add the word "often" OLD: " Multiple servers of this type may be co-located on a single physical host, using different ports, and each of these can use different certificates. " NEW: " Multiple servers of this type may be co-located on a single physical host, often using different ports, and each of these can use different certificates. " Some typos: 4. Section 1, 4th para: OLD: " Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" ciertificate from one of the widely-used CAs " NEW: " Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" certificate from one of the widely-used CAs " 5. Section 3.1, 2nd last para, s/case/cause/ OLD: " In this case, DNSSEC is not helpful, since an attacker could still case a denial of service by blocking all DNS responses for the target domain. " NEW: " In this case, DNSSEC is not helpful, since an attacker could still cause a denial of service by blocking all DNS responses for the target domain. " 6. Section 3.3, 3rd para, repeated word OLD: "As in Section Section 3.1 above" NEW: "As in Section 3.1 above"
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
