Re: [keyassure] TLSA record does not mandate the given certificate

"Richard L. Barnes" <rbarnes@bbn.com> Tue, 29 March 2011 08:41 UTC

Return-Path: <rbarnes@bbn.com>
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 E1C873A6ABE for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 01:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 DiXhGBPfbEpW for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 01:41:43 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 11DC23A6948 for <keyassure@ietf.org>; Tue, 29 Mar 2011 01:41:43 -0700 (PDT)
Received: from [128.89.255.146] (port=52765 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q4UWC-000H8I-0E; Tue, 29 Mar 2011 04:43:16 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <alpine.LFD.1.10.1103290430110.2105@newtla.xelerance.com>
Date: Tue, 29 Mar 2011 10:43:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B7AD439-2F88-4D8B-A58D-A32552D1E846@bbn.com>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com> <4672.1301340852@marajade.sandelman.ca> <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@mail.gmail.com> <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz> <alpine.LFD.1.10.1103290430110.2105@newtla.xelerance.com>
To: Paul Wouters <paul@xelerance.com>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
Subject: Re: [keyassure] TLSA record does not mandate the given certificate
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: Tue, 29 Mar 2011 08:41:44 -0000

I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

The relationship between DANE and PKIX is one of the topics for discussion at the DANE meeting tomorrow.  As I'll present (in a discussion too long for this email), they can actually work together very naturally.

--Richard



On Mar 29, 2011, at 10:34 AM, Paul Wouters wrote:

> On Tue, 29 Mar 2011, Jay Daley wrote:
> 
>> Two questions:
>> 
>> 1.  How is the current text in 3. not good enough?
>> 
>> "If a match between one of the certificate association(s) and the
>>  server's end entity certificate in TLS is found, the TLS client
>>  continues the TLS handshake.  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
>>  "access_denied" error."
> 
> I am assuming we will see deployment of DANE and PKIX alongside,
> where there might be contradictions or discrepancies between these two
> (or even other methods of obtaining this information out of band). I
> think what should be stated is that the "DANE validation path" should
> be aborted. We should not dictate to abort the TLS handshake. It would
> be up to a client/browser to implement one or more trust anchor methods
> (PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only
> after all its trusted methods have failed.
> 
> Paul
> 
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure