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

Benjamin Kaduk <> Mon, 23 October 2017 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28D8C13A2B8 for <>; Mon, 23 Oct 2017 15:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23cT45gke6hr for <>; Mon, 23 Oct 2017 15:30:50 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB9E6139EF2 for <>; Mon, 23 Oct 2017 15:30:49 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id v9NMRHN4003913; Mon, 23 Oct 2017 23:30:39 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=KIjZzkd/pLc/nTzcW9hnviu+tY9Piu8xOkwVYQY/JnI=; b=AtICGbYkn16aLAo6CZhJDvJZw0zMuJ04VVWB41LkLbngQL4DqxpFzgTlHMLQ9Vw79UDx gN/Jllip5FIsy1UE22WVwQ6NbE/Ws9edpJyPFF35cbh3eXAJnQ3j5xQmtDS1YG/kd8CB XgLz6bvD2rIUy/9GQNuSWcm7xL0t/gqhwDFj1BCe4MfVWMqkc1Aoa0GVuSoaXSl9Q71P sCIdLjwBvgc6knbamOqVi+Fq0O+0fPQPcWP8GVDpEzsuDcX19DApLMs/QtTGTDFaSgTs 7dRP8u9AshSYex5FGPHu05fjKvhrhdLaTE/2Q/v3lXl5pvU/CT+iHlB5R75AKLCQnnBs zQ==
Received: from prod-mail-ppoint4 ([]) by with ESMTP id 2dquad02g9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Oct 2017 23:30:39 +0100
Received: from pps.filterd ( []) by ( with SMTP id v9NMPpfv007522; Mon, 23 Oct 2017 18:30:38 -0400
Received: from ([]) by with ESMTP id 2dr1jwr7sr-1; Mon, 23 Oct 2017 18:30:38 -0400
Received: from [] ( []) by (Postfix) with ESMTP id A782F20066; Mon, 23 Oct 2017 16:30:37 -0600 (MDT)
To: "Ackermann, Michael" <>, "Salz, Rich" <>, Stephen Farrell <>, Darin Pettis <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Benjamin Kaduk <>
Message-ID: <>
Date: Mon, 23 Oct 2017 17:30:37 -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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , 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-1710230316
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_11:, , 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-1710230316
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: Mon, 23 Oct 2017 22:30:51 -0000

On 10/23/2017 01:42 PM, Ackermann, Michael wrote:
>  But as stated in several previous Emails, the fact that TLS 1.2 is still available,  does not mean that we won't  have applications, business units or other entities that require TLS 1.3 and we will need to manage, monitor and secure these, as well as older versions.

This seems sufficiently hypothetical so as to be non-actionable.

That is, I assume that any sufficiently large enterprise must have some
sort of architecture review process before a new system is deployed (and
if one does not, it seems highly unlikely to be secure).  There would
need to be some resolution of the conflict between those parties
"requiring" monitorability and those parties "requiring" TLS 1.3 before
such a system could get approved and approach deployment, so I feel
obligated to insert "require" into scare quotes and attribute no real
meaning to the statement.

As was stated previously, this is a case of being stuck between a rock
and a hard place.  While it is reasonable to investigate changing both
of the rock and the hard place, it seems unwise to presume that it is
one or the other specifically that must change.  You assert in a
different message that it would be very expensive and time consuming to
change "virtually every platform and application, not to mention all the
management, monitoring, and security platforms" (e.g., the "hard
place"), and I do not disagree.  It would also be expensive and time
consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the
way(s) being proposed; unfortunately, the error bars on this cost
estimate are necessarily quite large so as to take into account the risk
of catastrophic breakdown of the security of the Internet.   It seems
pretty clear that various parties involved in this conversation are
applying different metric functions to weight these various costs, which
makes it hard to see a path that would appease everyone.

In that same "different message" you also mention that you have come to
expect backwards compatibility, but can you really expect backwards
compatibility without limit?  Does Windows 10 run MS-DOS executables? 
Can a Kerberos principal who last set their password using Kerberos 4
expect to interoperate in a modern Kerberos 5 deployment?  Can you still
log into a shell server via telnet?  There are many arguments in support
of backwards compatibility, but they are not universal, and history
provides plenty of precedent for security eventually overriding
backwards compatibility.  So where would you put the boundary on the
backwards compatibility for static RSA in TLS or equivalent
non-forward-secrecy mechanisms?  Would you propose infinite
compatibility in this space with no bound?  Ten years from now?  When a
quantum computer can quickly factor 2048-bit RSA keys?  There are no
doubt folks here would claim that the writing has been on the wall for
five years or more that static RSA was out and forward secrecy was on
the way in, and that now is the right time to draw the line and drop the
backwards compatibility.    In fact, there is already presumed WG
consensus for that position, so a strong argument indeed would be needed
to shift the boundary from now.  I won't say that no such argument can
exist, but I don't think we've seen it yet.