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

Benjamin Kaduk <bkaduk@akamai.com> Fri, 20 October 2017 01:06 UTC

Return-Path: <bkaduk@akamai.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 E5B7D13495C for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 18:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 2cdu0k_8Xy8H for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 18:06:27 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8BF1321D8 for <tls@ietf.org>; Thu, 19 Oct 2017 18:06:27 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9K13Mrj003480; Fri, 20 Oct 2017 02:06:24 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=6Gh/555SXHbahmfvWIpYkZNJaXllEP6rZIMFaj8OtpU=; b=TC+7zX6XaTIQapbTzKE0kfFZZLM2r8t2LtO98usGTQDyjiyBtfdOsNwuBaQ6oaDMl00V l79eEOT5AIB7eHwAz27Sv5HmQOe85v43E4Yl5oh6rgJAuNWKaFMvaCi9TjzySvbMWann OJM1CHpG9me5svF/cQ7U7kMBzWvelsSKyx/gY3gr38Wu4OQhyvR1AeDcgbSVTjpiVl1P HWTwdHEdWtjX8AD6M5yUJBCQUr6+iF1emx40x36VxrZxDMKogoQbobzU91lG3+3b7tqK 65rc8XRP64Dt9vLZrkoT0gApqLkYlwl0IT3645uIOivG8ZdIq7EUiGzFrFkuW4B9SVpf yA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2dpg7dvehc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 02:06:24 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9K16JPr002563; Thu, 19 Oct 2017 21:06:23 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwuh50k-1; Thu, 19 Oct 2017 21:06:21 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 51AA71FC85; Fri, 20 Oct 2017 01:06:19 +0000 (GMT)
To: Darin Pettis <dpp.edco@gmail.com>, Paul Turner <PAUL.TURNER@venafi.com>, "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
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>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <c62d24eb-762b-1564-215b-8e982a4730fb@akamai.com>
Date: Thu, 19 Oct 2017 20:06:19 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------846DA70AAC404F0FD1F44C2B"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200015
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200014
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jaTYcw_oRbR-h8tZu7aR-Crh1Tw>
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 01:06:32 -0000

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