Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Russ Housley <housley@vigilsec.com> Fri, 20 October 2017 19:16 UTC

Return-Path: <housley@vigilsec.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 8AC78134308 for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 12:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 GUYYbB3L0x1T for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 12:16:29 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ADA133049 for <tls@ietf.org>; Fri, 20 Oct 2017 12:16:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5E72300572 for <tls@ietf.org>; Fri, 20 Oct 2017 15:16:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vF7OVpbdY5Vm for <tls@ietf.org>; Fri, 20 Oct 2017 15:16:27 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 33D1330026A; Fri, 20 Oct 2017 15:16:27 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <52709DEA-6820-4C88-8663-C6D403C1C638@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_03148C8E-404C-41C9-A611-4B2AE046429A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 20 Oct 2017 15:16:26 -0400
In-Reply-To: <c62d24eb-762b-1564-215b-8e982a4730fb@akamai.com>
Cc: IETF TLS <tls@ietf.org>
To: Benjamin Kaduk <bkaduk@akamai.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <c62d24eb-762b-1564-215b-8e982a4730fb@akamai.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9sOt7815ckw055AdF5zrijG5PvA>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Fri, 20 Oct 2017 19:16:30 -0000

> On Oct 19, 2017, at 9:06 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> On 10/19/2017 05:30 PM, Darin Pettis wrote:
>> 
>> The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol. 
>> 
> 
> But the "rhrd" draft does not require any changes to the core TLS 1.3 protocol, and in fact I have heard several key participants say that any "visibility" changes must not require changes to the core protocol.  If the "visibility" work will be done via extensions, then there is no ordering requirement for their specification with respect to the core work, there is only an ordering requirement between them and adoption of TLS 1.3 in enterprises.  Do you want to argue that a year timescale is too slow for enterprise adoption of TLS 1.3?  If not, I continue to not see a reason to address "visibility" now.

Ben:

I do not see the visibility extension taking any resources away from the completion of TLS 1.3, so I do not see any reason to make it wait.

Russ