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

Zack Weinberg <zack.weinberg@sv.cmu.edu> Tue, 29 March 2011 01:00 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 7E2CC3A6AA9 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level:
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 esrfcfIUV413 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:00:55 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 75E7128C0E7 for <keyassure@ietf.org>; Mon, 28 Mar 2011 18:00:55 -0700 (PDT)
Received: by vws12 with SMTP id 12so3230824vws.31 for <keyassure@ietf.org>; Mon, 28 Mar 2011 18:02:33 -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=SCrbzeJH2NYFEILo2BiHHQCVLul4j4eiaVNVlVxd7N4=; b=VMhBcrp82X24ojOitA+9yfNwFRwa3rkNiah96rZ3xnfeItkIPVT0B9rqSaaolFhQTR csJC5Wwiidmmuy1wP4Z++QFBr6lln2KL+d74DmBVRCO6ZReTts4djotGYu/jvS13T1G3 oKv3hNMD9JaCCHRLXqqjFHsfKlq6FNB6QsPQ4=
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=MP0vc33VWglLADE4fbgtsXM0JEzwwZ/FHfmm5xTB2XpIT29F0NdSm4ZmA1GfBqTm98 i6J9IAWQjyX8fR5Chg36Byv6FED+GxqAgVX4wo9OW5pvqlEUMIXx/qI8mB2fqDaCFf6w dI3ob/4R7nTt5YACumHBfBLpY2FSjrYuIoLKs=
MIME-Version: 1.0
Received: by 10.52.18.102 with SMTP id v6mr5630657vdd.224.1301360550821; Mon, 28 Mar 2011 18:02:30 -0700 (PDT)
Sender: zack.weinberg@gmail.com
Received: by 10.52.166.34 with HTTP; Mon, 28 Mar 2011 18:02:30 -0700 (PDT)
In-Reply-To: <AA2DCA69-7C46-40DD-A444-65009480CD3C@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>
Date: Mon, 28 Mar 2011 18:02:30 -0700
X-Google-Sender-Auth: GyePyGpsYgLnzw4KZh-9CLsSnew
Message-ID: <AANLkTinb0UBewLn-Dk2GPS6+8t9Y8DSO889TGWLeXNXZ@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 01:00:56 -0000

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.

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.

> 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), 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