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"