Re: [TLS] Interim meeting information

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 12 September 2018 15:22 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 D4813130DDA for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 08:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 lsv2x5f1a-fr for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 08:22:26 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4D8130DC6 for <tls@ietf.org>; Wed, 12 Sep 2018 08:22:26 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 863AA37EAB for <tls@ietf.org>; Wed, 12 Sep 2018 11:22:24 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAO8oSXnx-J5aqir24L8uLNcVg5L2zFucmbRV6=S3bZMaMrHAJQ@mail.gmail.com>
Date: Wed, 12 Sep 2018 11:22:23 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: tls@ietf.org
Message-Id: <80104E7B-7442-43A0-BFD4-18301B05F9EE@dukhovni.org>
References: <CAO8oSXnx-J5aqir24L8uLNcVg5L2zFucmbRV6=S3bZMaMrHAJQ@mail.gmail.com>
To: tls@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WDaCVqbE5vwclwaBsZlRx2LjbWU>
Subject: Re: [TLS] Interim meeting information
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 12 Sep 2018 15:22:29 -0000


> On Sep 12, 2018, at 10:58 AM, Christopher Wood <christopherwood07@gmail.com> wrote:
> 
> Below is an agenda for Friday's virtual interim meeting, followed by
> the meeting information. This information is also available online
> [1]. We are looking for volunteers to lead each agenda item. Please
> respond on list or to the chairs directly if you're willing to do so.
> 
> Best,
> Chris, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/agenda-interim-2018-tls-01-tls-01/
> 
> ~~~
> 
> Agenda: Discuss draft-ietf-tls-dnssec-chain-extension
> - Problem statement recap.
> - Discuss client-side caching semantics and use cases.
> - Discuss need (or not) for extension pinning.
> - Review some open gaps:
>  - Lack of a port number in the client side of the extension.
>  - Lack of downgrade protection for existing applications.
>  - Lack of discussion of virtual hosting.
>  - Needless complexity from RRset ordering requirements.

Thanks.  There are a couple of other gaps that'll come to the surface
once we get down to work updating the text.  One issue is that draft-07
did not require SNI from the client, and seemed to suggest that the
server can in any case use the extension with some default name, even
when it does not recognize the client's SNI.  This does not work at
all well.

I've prepared text that makes SNI a co-requisite with dnssec_chain,
and ensures that the server's extension matches the requested SNI
or else the server decline the dnssec_chain extension.

Denial of existence text needed a bit more polish, ...  Also
added some commentary on the need for NSEC records any time
something in the chain is synthesized via wildcard records.
(Some the background discussion is the git commit message).

When we actually get to discuss virtual hosting use-cases it'll
be useful point out a deviation from RFC7671, which suggests
CNAME chasing that simply can't be made to work with dnssec_chain,
(and that's OK).

I've also realized that even with direct DNS lookups the CNAME chasing
in RFC7671 is not a good fit for some applications (like web browsers)
where the server's post-handshake behaviour depends on the SNI
value.  It seems that 7671 had a bit too much SMTP tunnel-vision, ...
sorry about that.  So we could even consider a couple of updates
to 7671 here, or in a separate draft.  Perhaps the UKS draft from
Richard Barnes could get adopted and also fix-up the CNAME
issues from 7671.

-- 
	Viktor.