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

Jay Daley <jay@nzrs.net.nz> Tue, 29 March 2011 00:38 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 E01E83A6A97 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 17:38:17 -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 HoxLzC5IKIv1 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 17:38:17 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id E5C8A3A6A90 for <keyassure@ietf.org>; Mon, 28 Mar 2011 17:38:16 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 7C1162DA68E; Tue, 29 Mar 2011 13:39:57 +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 WOH4rgTJGq3b; Tue, 29 Mar 2011 13:39:57 +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 295962DA2EB; Tue, 29 Mar 2011 13:39:57 +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: <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@mail.gmail.com>
Date: Tue, 29 Mar 2011 13:39:52 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com> <4672.1301340852@marajade.sandelman.ca> <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@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 00:38:18 -0000

On 29/03/2011, at 10:01 AM, Zack Weinberg wrote:

>>    Zack> The presence in the DNS of a trusted TLSA record is an assertion
>>    Zack> by the zone administrator that the legitimate server(s) for that
>>    Zack> host, protocol, and port will use certificate bundles that can be
>>    Zack> associated with the domain name by that record (as defined in
>>    Zack> section 3.1), and no others.
>> 
>>    Zack> Therefore, a DANE client in possession of a trusted TLSA record
>>    Zack> for a server MUST determine whether that TLSA record associates
>>    Zack> the server's domain name with the certificate bundle it provides
>>    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
>>    Zack> the end-entity certificate and abort the TLS handshake with an
>>    Zack> "access_denied" error.  This rule applies even if the end-entity
>>    Zack> certificate would have been trusted in the absence of the TLSA
>>    Zack> record.
> 
> If it's not, please let me know how I could improve it.

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."

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 ..."

Jay

> 
> zw
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure


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