Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 04 July 2017 16:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F313132207 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3WNQb6INkHP for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:14:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4AC132209 for <tls@ietf.org>; Tue, 4 Jul 2017 09:14:43 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 304C87A32F1 for <tls@ietf.org>; Tue, 4 Jul 2017 16:14:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com>
Date: Tue, 4 Jul 2017 12:14:42 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rAMndzQLEHlPVVVaKRiqP-R4wgA>
Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2017 16:14:47 -0000

> On Jul 4, 2017, at 11:33 AM, Shumon Huque <shuque@gmail.com>; wrote:
> 
> Yes, in fact the previous sentence to the one you quoted did say this more or less: " ... return a serialized authentication chain in the Certificate message associated with the end entity certificate being validated ". I would propose rewording that a bit and removing the last quoted sentence entirely:
> 
>    Servers receiving a "dnssec_chain" extension in the ClientHello, and
>    which are capable of being authenticated via DANE, SHOULD return a
>    serialized authentication chain in the extension block of the Certificate 
>    message containing the end entity certificate being validated, using the 
>    format described below.

Why the end-entity certificate, and not the final certificate
sent by the server?  With anything but DANE-EE(3) the TLSA
records can't be processed against the server's certificate
message until *all* the server certificates have been received.

So instead of squirreling away the DNS data while waiting for
all the server certificates to arrive, it may make more sense
to receive the TLSA records (and associated signatures, CNAMEs,
DNAMEs, ...) once all the server certificates have been received.

Of course either way one still buffers all the server certificates,
so buffering the TLSA records is not a major issue.  It's just that
I don't see a compelling argument for sending the TLSA records with
the EE certificate.  Perhaps send them with any of the server
certificates, it probably makes no difference which...

-- 
	Viktor.