[secdir] SecDir Review of draft-ietf-dane-protocol-19

Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 26 April 2012 20:08 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0623F21F87AA; Thu, 26 Apr 2012 13:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OBflyWElrlSS; Thu, 26 Apr 2012 13:08:54 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil []) by ietfa.amsl.com (Postfix) with ESMTP id B44D021F87A5; Thu, 26 Apr 2012 13:08:52 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net []) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q3QK8pJ4027801; Thu, 26 Apr 2012 16:08:51 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 []) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q3QK8m23002989; Thu, 26 Apr 2012 16:08:49 -0400 (EDT)
Received: from siduri.fw5540.net ([]) by chacs.nrl.navy.mil (SMSSMTP with SMTP id M2012042616084817191 ; Thu, 26 Apr 2012 16:08:48 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary=Apple-Mail-13-681443327
Date: Thu, 26 Apr 2012 16:08:48 -0400
Message-Id: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil>
To: draft-ietf-dane-protocol.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] SecDir Review of draft-ietf-dane-protocol-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 20:08:57 -0000

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@nrl.navy.mil