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

"Blumenthal, Uri - 0553 - MITLL" <> Fri, 20 October 2017 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3C95134222 for <>; Fri, 20 Oct 2017 07:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bB_vkUtPCxNG for <>; Fri, 20 Oct 2017 07:28:40 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 69EA01331D9 for <>; Fri, 20 Oct 2017 07:28:40 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id v9KESNJT035552 for <>; Fri, 20 Oct 2017 10:28:39 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Date: Fri, 20 Oct 2017 14:14:21 +0000
Message-ID: <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3591339260_12856504"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_07:, , 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-1710200203
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Oct 2017 14:28:43 -0000

+1 to Rich.




Uri Blumenthal


From: TLS <>; on behalf of Rich Salz <>;
Date: Friday, October 20, 2017 at 09:59
To: Darin Pettis <>;, ""; <>;
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00


Ø  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. 


You achieve your needs right now by sharing the origin’s RSA key with your debugging agents.  You can achieve the same needs in TLS 1.3 by keeping that architecture, although more information must be shared.  This preserves the architecture and becomes “just” implementation.  This has been brought up before.


The first draft showed how to do this purely on the server side.  Some members of the WG rose up and wanted explicit opt-in. The new draft does that.  In retrospect, it turns out that opt-in is worse, mainly that there is no way to guarantee that this does not “escape” onto the public Internet. This makes sense, if you require opt-in from the client, then it is not surprising that, other entities besides the two parties engaged in the TLS protocol could, well, *require* clients to opt-in.  As I and others have tried to show in email exchangers with Paul, this is a fundamental change to the nature of how TLS is used.


Finally, as has also been mentioned, nobody is preventing you from keeping your servers at TLS 1.2 or earlier.  TLS 1.2 was defined by RFC 5246 in 2008. A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will happen any faster?


You have not made your case.