Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

Scott Schmit <i.grok@comcast.net> Sun, 20 February 2011 04:21 UTC

Return-Path: <i.grok@comcast.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455EE3A7090 for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 20:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.796
X-Spam-Level:
X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XovQv6Rz3ega for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 20:20:59 -0800 (PST)
Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id D75423A6D9C for <keyassure@ietf.org>; Sat, 19 Feb 2011 20:20:59 -0800 (PST)
Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta10.emeryville.ca.mail.comcast.net with comcast id A4Mc1g0011smiN4AA4MdP9; Sun, 20 Feb 2011 04:21:37 +0000
Received: from olympia.mars.sol ([68.33.77.0]) by omta20.emeryville.ca.mail.comcast.net with comcast id A4Mc1g00400PQ6U8g4Mcde; Sun, 20 Feb 2011 04:21:37 +0000
Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1K4LZXw011480 for <keyassure@ietf.org>; Sat, 19 Feb 2011 23:21:35 -0500
Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1K4LXlw011478 for keyassure@ietf.org; Sat, 19 Feb 2011 23:21:33 -0500
Date: Sat, 19 Feb 2011 23:21:33 -0500
From: Scott Schmit <i.grok@comcast.net>
To: keyassure@ietf.org
Message-ID: <20110220042133.GB7481@odin.mars.sol>
Mail-Followup-To: keyassure@ietf.org
References: <20110210224502.31025.53023.idtracker@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20110210224502.31025.53023.idtracker@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Feb 2011 04:21:01 -0000

On Thu, Feb 10, 2011 at 02:45:02PM -0800, Internet-Drafts@ietf.org wrote:
> 	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
> 	Author(s)       : P. Hoffman, J. Schlyter
> 	Filename        : draft-ietf-dane-protocol-04.txt
> 	Pages           : 11
> 	Date            : 2011-02-10

Some of these are nits, some not:

Abstract:
---------

>  TLS and DTLS use certificates for authenticating the server.  Users
>  want their applications to verify that the certificate provided by
>  the TLS server is in fact associated with the domain name they
>  expect.  Instead of trusting a certification authority to have made
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  this association correctly, the user might instead trust the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  authoritative DNS server for the domain name to make that
>  association.  This document describes how to use secure DNS to
>  associate the TLS server's certificate with the the intended domain
>  name.

I would argue that in DNSSEC, each zone operator is a CA, just not a
PKIX CA.

How does this sound instead?

   TLS and DTLS use certificates for authenticating the server.  Users
   want their applications to verify that the certificate provided by
   the TLS server is in fact associated with the domain name they
   expect. DNSSEC provides a mechanism for a zone operator to sign DNS
   information directly.  This way, bindings of keys to domains are
   asserted not by external entities, but by the entities that operate
   the DNS.  This document describes how to use secure DNS to associate
   the TLS server's certificate with the the intended domain name.

(I used the text from the charter, I figured that's the least
controversial option).

Section 2.2:
------------

I'm not the first to mention this, but I think the overlap between the
certificate type and hash type is a bad idea. It allows nonsensical
combinations to be expressed with all the problems that go with it.

It would make much more sense for the certificate type to only indicate
the kind of certificate that is referenced, and the second field
indicates how that reference is formatted in the RDATA. This would
change the text to something like:

   o  A one-octet value, called "certificate type", specifying the
      provided association that will be used to match the target
      certificate.  This will be an IANA registry in order to make it
      easier to add additional certificate types in the future.  The
      types defined in this document are:
 
         1 -- An end-entity certificate
 
         2 -- A certification authority's certificate
 
   o  A one-octet value, called "reference type", specifying how the
      certificate association is presented.  This value is defined in a
      new IANA registry.  The types defined in this document are:
 
         0 -- Full certificate in DER encoding
 
         1 -- SHA-1 hash of the certificate in DER encoding
 
         2 -- SHA-256 hash of the certificate in DER encoding
 
         3 -- SHA-384 hash of the certificate in DER encoding
 
      Using the same hash algorithm as is used in the signature in the
      certificate will make it more likely that the TLS client will
      understand this TLSA data.

Unless these are all MUSTs, the document needs to indicate which are
required and which are not.

Section 3:
----------

Should "If the application receives zero usable certificate
associations, it processes TLS in the normal fashion." be a MUST?

The last statement in section three should probably be:

"If no match between the usable certificate association(s) and the
server's end entity certificate in TLS is found, the TLS client MUST
abort the handshake with an "unknown_ca" error."

This adds "usable" to make clear the distinction between this and the
"continue as usual" case. Also, I changed access_denied to unknown_ca.
According to RFC 5246:

>  unknown_ca
>     A valid certificate chain or partial chain was received, but the
>     certificate was not accepted because the CA certificate could not
>     be located or couldn't be matched with a known, trusted CA.  This
>     message is always fatal.
>
>  access_denied
>     A valid certificate was received, but when access control was
>     applied, the sender decided not to proceed with negotiation.  This
>     message is always fatal.

To me, unknown_ca looks like the correct error -- DANE is about allowing
DNSSEC to redefine what the trusted CAs are.

Section 4.2/4.3:
----------------

Value 255 is unspecified. Is this a typo, or was that intended to be
reserved as experimental?

We need to specify which algorithms are required, optional, etc.

I don't think the registry policies are sufficiently restrictive to
prevent using up the available space. At minimum it should require
expert review if not IETF Review. Otherwise, the only limitation on
registration is an independent RFC.

Just to demonstrate how quickly the hash type (or whatever it turns
into) could be used up, NIST is currently holding a competition to
decide what algorithm will become SHA-3. They are now on their final
round of competition, and there are no further opportunities for tweaks
to the algorithms. So, all those algorithms are permanent and readily
available.

So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4
Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3),
SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and
the existing entries from dane-04, and you have 37 entries--about 1/7th
of the available space.

Section 5:
----------

You have two references to just A records and three to A/AAAA records.
That's probably incomplete editing to change them all to the latter.

Also, I don't understand this paragraph:

>  A DNS administrator who goes rogue and changes both the A and TLSA
>  records for a domain name can cause the user to go to an unauthorized
>  server that will appear authorized, unless the client performs
>  certificate validation and rejects the certificate.  That
>  administrator could probably get a certificate issued anyway, so this
>  is not an additional threat.

What certificate validation is the client going to do that would detect
this attack?

The good news about this kind of attack is that it can be detected (by
machine, admittedly) since all the certificates/associations are
published in the DNS (unlike a rogue PKIX CA).

Maybe this is a lack of operational experience, but I'm not sure I
understand why adding or changing TLSA information would be less
protected than for A/AAAA records?

Hope this helps.

-- 
Scott Schmit