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

Paul Wouters <paul@xelerance.com> Tue, 29 March 2011 08:33 UTC

Return-Path: <paul@xelerance.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 B17513A6948 for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 01:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599]
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 xy0wC4LEil38 for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 01:33:13 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id AD7C83A6873 for <keyassure@ietf.org>; Tue, 29 Mar 2011 01:33:13 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5E36CC59D; Tue, 29 Mar 2011 04:34:49 -0400 (EDT)
Date: Tue, 29 Mar 2011 04:34:49 -0400 (EDT)
From: Paul Wouters <paul@xelerance.com>
To: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz>
Message-ID: <alpine.LFD.1.10.1103290430110.2105@newtla.xelerance.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>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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:33:14 -0000

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