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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 04 July 2017 16:27 UTC

Return-Path: <ilariliusvaara@welho.com>
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 095E31322D4 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 sdqMraTAxFev for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:27:20 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78D1322D1 for <tls@ietf.org>; Tue, 4 Jul 2017 09:27:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 780A92E88C for <tls@ietf.org>; Tue, 4 Jul 2017 19:27:18 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7JBt_JBblEaL for <tls@ietf.org>; Tue, 4 Jul 2017 19:27:18 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3054221C for <tls@ietf.org>; Tue, 4 Jul 2017 19:27:17 +0300 (EEST)
Date: Tue, 4 Jul 2017 19:27:17 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: TLS WG <tls@ietf.org>
Message-ID: <20170704162717.lb6pqfsm3debgucq@LK-Perkele-VII>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com> <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1861626B-4D85-4885-8377-3B0DF819E357@dukhovni.org>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_2HWEvwvGw8qdPDvaUeP8Mpd1wU>
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:27:22 -0000

On Tue, Jul 04, 2017 at 12:14:42PM -0400, Viktor Dukhovni wrote:
> 
> > 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.

Well, the optimal would be the certficiate record pertrains to.
However, since RRsets are atomic, this is not possible.
 
> 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...

The entiere Certificate message should be loaded into memory anyway.
And one definitely does not want to merge records.


-Ilari