Last Call Review of draft-ietf-dane-use-cases-

Request Review of draft-ietf-dane-use-cases
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-07-19
Requested 2011-07-09
Authors Richard Barnes
Draft last updated 2011-08-05
Completed reviews Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-dane-use-cases-secdir-lc-kaufman-2011-08-05
Review completed: 2011-08-05


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

DANE is the latest in a long series of attempts to use DNSSEC to securely distribute the public keys corresponding to DNS names as an alternative/supplement to the PKIX based PKI that has evolved to be both not very secure and not very convenient. Using DNSSEC as an alternative/supplement is a great idea, but it has failed many times in the past both for political reasons and because DNSSEC wasn't really there yet. This document is a requirements document, which gives it license to leave out a few of the more controversial details of the design.

I am strongly supportive of this effort, and have no complaints with any of the contents of this document. There are a few issues that I think could have been addressed more clearly, but presumably that will come in future documents.

DANE is primarily pitched in this document as a supplement to the existing PKIX based PKI, and also it is stated that the keys are only intended to be used in the context of TLS (mostly for server authentication, but optionally also for client authentication if the client is identified by a DNS name). This means that having DANE information posted in DNS could cause a connection that succeeded without DANE to fail, but it could not cause a connection that failed without DANE to succeed. In this context, it helps address the security problems with the de facto Internet PKI, but not the convenience problems. It does permit, however, (in scenario #3) the DANE information to replace the Internet PKI (in the sense of supporting TLS connections to servers that don't have certificates from configured trust roots). It is left to endnode configuration to decide whether to trust such information, and the single biggest issue that will face people deploying DANE is whether to trust such information or not.

DANE will permit different kinds of information to be posted in DNS concerning how to authenticate entities claiming to represent a particular DNS name. This document doesn't say whether one of them will be a raw public key. That would be the most straightforward thing to do, but also the most controversial. What it emphasizes is the ability to specify which CA or CAs are allowed to issue certificates for a particular DNS name. This would close the biggest single security gap in the de facto Internet PKI - that any trust root can generate bogus certificates for any DNS name, and many of the trust roots are under the control of dubious entities. The document was not clear as to whether the CAs are identified by name or by public key, but references to its certificate imply they will be identified by both.

Interesting details:

The document calls for being able to co-locate multiple servers on a single physical host distinguished by different ports where different certificates are required to authenticate the services on the different ports. I don't know that PKIX supports that functionality, so this would be an extension.

The document does not mention co-locating multiple servers on a single physical host distinguished by different DNS names supplied in header fields, but that would fall out of any reasonable design.

The document calls for being able to work when the application service name is the result of following a DNS redirection chain (e.g., via CNAME or DNAME), but does not suggest a mechanism. There may be technical options with different security semantics... this will be an interesting area to watch.

There is a suggestion on page 8 (ref: "a downgrade attack") that DANE information can be used to inform a client that a service is capable of accepting TLS connections and that a client might (based on that information) refuse to connect not over TLS, but no mention of this important feature elsewhere in the document.


P2: "ciertificate" -> "certificate"
P10: "Opportunistic Security" -> "Opportunistic Security:"