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