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

Jay Daley <jay@nzrs.net.nz> Tue, 29 March 2011 01:26 UTC

Return-Path: <jay@nzrs.net.nz>
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 BB9F828C143 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 tNqBytHCxEYh for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:26:20 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A70AE28C142 for <keyassure@ietf.org>; Mon, 28 Mar 2011 18:26:20 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CA0082DAA91; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ria7SDW-zkMY; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 981842DA68E; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <AANLkTinb0UBewLn-Dk2GPS6+8t9Y8DSO889TGWLeXNXZ@mail.gmail.com>
Date: Tue, 29 Mar 2011 14:27:57 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD2940CC-DF2A-4D1B-BC99-7D6CE9411B4E@nzrs.net.nz>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com> <4672.1301340852@marajade.sandelman.ca> <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@mail.gmail.com> <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz> <AANLkTinb0UBewLn-Dk2GPS6+8t9Y8DSO889TGWLeXNXZ@mail.gmail.com>
To: Zack Weinberg <zack.weinberg@sv.cmu.edu>
X-Mailer: Apple Mail (2.1084)
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 01:26:21 -0000

On 29/03/2011, at 2:02 PM, Zack Weinberg wrote:

> On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley <jay@nzrs.net.nz> 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."
> 
> Only in being more confusing than I would like.  I think it's vital to
> be crystal clear how a client should behave in all cases.

Sorry to be a pain, but I struggle to see how this is confusing.  Can you explain?

> By highlighting this text you reassure me that my changes to emphasize
> the exclusivity properties of TLSA really are editorial, though, so
> that's a relief.

Good.

>> 2.  Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology)
>> 
>> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."
> 
> I changed the terminology (see text above this),

I'm not sure what you are referring to.  Did I miss some text?

Jay

> again, to reduce
> confusion.  An entire certificate bundle does not match anything
> anymore, it can only be associated.  Only single certificates match.
> 
> You're right, though, I forgot to consider the case of multiple TLSA
> records.  I'll need to tweak wording throughout to fix that, I think.
> 
> zw


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840