Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 05 October 2010 19:03 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5941C3A70DA; Tue, 5 Oct 2010 12:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.555
X-Spam-Level:
X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 jix4IqZDdigz; Tue, 5 Oct 2010 12:03:01 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5EAE23A6FED; Tue, 5 Oct 2010 12:03:01 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o95J3tu4000412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 19:03:57 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o95CmLZC002871; Tue, 5 Oct 2010 19:03:55 GMT
Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 664713501286305377; Tue, 05 Oct 2010 12:02:57 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Oct 2010 12:02:57 -0700
Date: Tue, 5 Oct 2010 14:02:52 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Message-ID: <20101005190251.GY9501@oracle.com>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org
Subject: Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 19:03:02 -0000

On Fri, Oct 01, 2010 at 11:29:35AM -0400, Phillip Hallam-Baker wrote:
> What I object to is the approach being taken which is to use DNSSEC to
> replace PKIX certificate validation entirely.
> 
> Now the proponents are trying to downplay this by saying that 'all' they are
> doing is to tell people to 'ignore' PKIX validation. But that approach
> really offends my sense of layering.

I think the layering argument is the strongest argument here.  To be
sure, the KEYASSURE approach offends my sense of layering too, but not
in the same way: IMO this is a change to how certificate validation is
done, therefore an update to RFC5280, ISTM, is required.

What I'd like to see is for the DNSSEC approach to certificate
validation be considered as a change to TLS and/or PKIX.  That is:

 - RFC5280 should be updated to describe DNSSEC-based validation of
   certificates.

   There are a number of security considerations here that must be
   considered in the context of PKIX.  For example: can a DNSSEC-
   validated certificate be a CA certificate, and if so, what might its
   scope be?  Are there implied naming constraints?  Or: when is it OK
   to try one (traditional PKIX valdiation) or the other (DNSSEC), and
   when is it OK to fallback on the other?

   (Perhaps this is what you meant by giving the attacker two
   infrastructures to attack.  If the validation policy of the rp can be
   forced to fallback on a less preferred mechanism via a DoS attack,
   then the attacker has something to work with.)

   I've _not_ reviewed the KEYASSURE documents, so I'm not sure if these
   security considerations are being addressed/documented.

 - TLS implementations should offer applications whatever choices the
   update to RFC5280 requires, if any.  Choices such as: validation
   policy choices (trad-PKIX-only, DNSSEC-only, trad-PKIX-and-DNSSEC,
   DNSSEC-fallback-on-trad-PKIX-only-if-NXDOMAIN-is-secured, DNSSEC-
   fallback-on-trad-PKIX).

   TLS doesn't have abstract interfaces, but some text regarding this in
   an update to TLS 1.2 seems appropriate to me.  Alternatively, such
   text could belong in the RFC5280 update, but even then, I think TLS
   implementors specifically need to be made aware of this new
   certificate validation option and its security considerations.

The main security consideration here is, I think, about when to try one,
the other, or both of traditional PKIX or DNSSEC certificate validation.

Nico
--