Last Call Review of draft-ietf-dane-use-cases-
review-ietf-dane-use-cases-secdir-lc-kaufman-2011-08-05-00

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.

Typos:

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