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

Zack Weinberg <zack.weinberg@sv.cmu.edu> Tue, 29 March 2011 23:22 UTC

Return-Path: <zack.weinberg@gmail.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 AFA5F3A6AA2 for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 16:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.277
X-Spam-Level:
X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 D2Ua8OV0vvGu for <keyassure@core3.amsl.com>; Tue, 29 Mar 2011 16:22:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 074C73A6992 for <keyassure@ietf.org>; Tue, 29 Mar 2011 16:22:13 -0700 (PDT)
Received: by vxg33 with SMTP id 33so693176vxg.31 for <keyassure@ietf.org>; Tue, 29 Mar 2011 16:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m0KTgvX4rocgm6+I0pNmJ+7cX0RzuxvQK+SWt4n9VfM=; b=QMHzMyef5eZMNa4Bd7PeVcRyqaak0S+0oLkSk8DzPqjkLhdCXe99DxP+7v8IJn0F4Z tpKEmTNW2z2Ug02oZaw7iyFlt9TgQhA1ecoOVMqBhhFiztToNG3pEAgX6oo47NLL/9C/ g96TUvno2qQLXAfCM82FVhsrAvDXmPA1Y5Cp8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q4Tz5PGWI2jeFwM1Vy3WyccuH3vSZY/IeRsve6idCka1cWS/r5aZYZsBGjZzVAYB7J Q1XS0VyiBW8iaY1lGciEqdj79jPNRSALxV4XMB0XdBsd+ewA8uKYN/R83YHI66eyzkht b1fRElVtOX47vgT2HgskR0yhxufRH/bNCpUMk=
MIME-Version: 1.0
Received: by 10.52.0.4 with SMTP id 4mr634505vda.104.1301441032075; Tue, 29 Mar 2011 16:23:52 -0700 (PDT)
Sender: zack.weinberg@gmail.com
Received: by 10.52.166.34 with HTTP; Tue, 29 Mar 2011 16:23:52 -0700 (PDT)
In-Reply-To: <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> <DD2940CC-DF2A-4D1B-BC99-7D6CE9411B4E@nzrs.net.nz>
Date: Tue, 29 Mar 2011 16:23:52 -0700
X-Google-Sender-Auth: XZwjQhx-r_xd3BJB5jx1hnPzOoQ
Message-ID: <AANLkTimViXFPfwMaNoPSUuGP2S5tHjkkKga=aVDpe2Rd@mail.gmail.com>
From: Zack Weinberg <zack.weinberg@sv.cmu.edu>
To: Jay Daley <jay@nzrs.net.nz>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 23:22:15 -0000

On Mon, Mar 28, 2011 at 6:27 PM, Jay Daley <jay@nzrs.net.nz> wrote:
>>> 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?

Had to think about it for a while, but my big problem with it is the
"match between one of the certificate associations and the end entity
certificate" language.   An _association_ is a weird thing to _match_.

There is also a jumble of MUST-language and non-MUST language in here
("the TLS client continues" versus "the TLS client MUST abort".

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

The "definitions" section in my proposal.  The way you'd say this in
my language is

   ... must determine whether the server's certificate bundle ... can
be associated with the
   server's domain name by at least one of the TLSA records for that
domain name ...

Note how the TLSA record is not itself an "association", it's just a
"record", whose effect is to _match_ one of the certificates in the
in-band bundle, and thus form an association between the bundle and
the _name_.

In my next draft, having taken on board some of Paul Wouters'
comments, I think I'll say that the association is between the
_server_ and the name.

zw