Last Call Review of draft-ietf-dane-protocol-
review-ietf-dane-protocol-secdir-lc-meadows-2012-05-04-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.

This draft gives the specification of a method for DNS-based authentication of
named entities (that is public key certificates) for

TLS.  The draft is written in response to a perception of the risk involved in
the current use of multiple Certificate Authorities (CAs)

to issue certificates.  Because CAs are large, they make inviting targets, and
because different CAs may be sign the same certificate,

compromise of even one CA could allow it to issue a replacement certificate
with a bogus key that would replace the legitimate certificate

signed by the honest CAs.  This has led to some incidents involving

compromise of major web sites involving millions of users.

Another approach is  to make use of the DNS infrastructure instead of public
CAs: keys are associated with domain names, and can only be signed

with a key associated with the parent of the domain name.  The keys would be
managed by the same entities that manage the domain name.

This has the advantage that an untrustworthy signer can only compromise keys in
its own subdomains, so the advantage of to an attacker

of compromising a single CA is lessened.

This document describes a TLSA Resource Record  that is used to associate a
certificate with the domain name where the record is found and

specifies its use in TLS.  This requires changes to the client software so that
clients are able to interpret the records, but no change to the server software.

The security considerations section is thorough and well-thought out.  It
consists of three parts.  The first part describes security risks not
necessarily (to my knowledge) related

to the choice of DNS domains rather than CAs, and describes possible
mitigations.  The second gives a comparison of the

security issues involved in relying on DNS domains rather than CAs; the authors
make it clear that this is not an open-and-shut case either

way, and that much is still unknown.  The third describes, and suggests
mitigations against, some security risks that are specific to DNS, having to do
with attacks based on deliberate mis-association

of TLSA records and DNS names.

 I only  have a couple of minor questions.  First,  the authors contrast the
 number of certificates signed by the  CAs and by the DNS domains.  However, it
 would

appear that as get closer to the root of the domain name tree, number of
certificates would get large, and that some domains, such as .com, would

be more likely to have certificates that are attractive to attackers than
others.  However, I don't know how large CAs get by comparison; if there are
some

figures available, that would help.  Secondly, it appears that all the risks
described in the first part of the security considerations apply equally as
well to the

current CA-based system as well, except that the risks attributed to rogue DNS
administrators would

instead be attributed to rogue CA's.   If that is so, it would be good to have
a sentence saying so.  On the other hand, if some of the risks apply only to
the new

system and not the current one, it would be good to know about these too.

Finally, a nit: what are the A/AAAA records referred to in the first part of
the security considerations section?  I could not find a definition in the
document.

Cathy Meadows

Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email:

catherine.meadows at nrl.navy.mil