Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Keith Moore <> Sat, 28 November 2020 00:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26B573A0982; Fri, 27 Nov 2020 16:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=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 NFbUxcDP3Boz; Fri, 27 Nov 2020 16:44:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D6E53A0980; Fri, 27 Nov 2020 16:44:26 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C60695C0174; Fri, 27 Nov 2020 19:44:25 -0500 (EST)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Fri, 27 Nov 2020 19:44:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SSY/lg HXxxhDfyzqMGMIWeCXQksrJfy5r+EMndTDHLs=; b=b1N4ECFW1fepRPPJM6qmZL b35Tb4ewUh+aiiX+aNizIa83xk3t1XgzQVPzXvJM27jK3kl9CANvmZBFLQEabErA Cslztr13P9jmfbVo1LkY1xgSB7vN8m7m2GUAYNwCLWJS2CY+hwSD8zN6lhDrtFrL aZMC0j0tDB+3MSEy4BEvQEf3E5KQuxIUHPqjdwxruj1O8Rg9DVk0NgodvMbeeyKr eEfeEdcPfFa1uGVXOwSEnevaFdUYopko2I1i5SJv0OET3yqnw+bwCpEOs6vYiUg3 9ILk6K4pF7qcb6fepx+XWcU/xdMzmw26vUbWyC4UPjqRHkNWDkPly9QBNr5FHurw ==
X-ME-Sender: <xms:aJ3BX2O22wopggwYshYqxqBaXrlpYaBr-h_pxxoxHvAqIpO8sMJVpQ> <xme:aJ3BX0-2o0r4FEDCDfCKBBzTCM_uqvevlHs_IczqP9P1-Ob6WUvY2ForLzdmShTaU m9If2KIZTp1sw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehhedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepudetfeekveevfe eltdekffeigeelkefgudevgedtvdehjefggffglefhvdeuudeinecuffhomhgrihhnpehi vghtfhdrohhrghenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:aJ3BX9Txs2f9MpRz7lbVvS1dMAirBQJBDZ4kLW-XhEVY76H2kQXJeA> <xmx:aJ3BX2vbNd_783grgnKlFiNE6_vDyfEPowPw_SRZ5vh0pH0G7CixXQ> <xmx:aJ3BX-dS-Lk6oDslE4I3jd07g7HsspnN5aJZA_mOFJD0k_5O3ExvEA> <xmx:aZ3BX2n1VekY35Z9xYGN42OQ8jOB4N7aDXu4lvEa8-m7wEO4xKqaOw>
Received: from [] ( []) by (Postfix) with ESMTPA id 4055D328005D; Fri, 27 Nov 2020 19:44:24 -0500 (EST)
References: <>
From: Keith Moore <>
Message-ID: <>
Date: Fri, 27 Nov 2020 19:44:23 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------7A79C7CA2ABDADD783A3E804"
Content-Language: en-US
Archived-At: <>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Nov 2020 00:44:29 -0000

While I agree that TLSv1.0 and TLSv1.1 should be avoided as much as 
possible, I believe this document fails to consider that there are old 
systems that are still in use that cannot be upgraded.   Strict 
implementation of the MUST NOT rules in this document can even prevent 
those systems from being upgraded at all, even when upgrades are 
available.   Strict implementation of the MUST NOT rules in this 
document can also make old embedded systems with built-in servers 
effectively unusable or require the operators of such systems to disable 
TLS entirely.

In general, it should not be assumed that old systems can be upgraded, 
or that old systems are feasibly replaced with newer systems.   There 
are several reasons for that.

  * One is that operating system vendors sometimes stop supporting old
    hardware, and client or server software vendors stop supporting old
    operating systems.
  * Some platforms are certified for medical use with specific versions
    of operating systems for which OS or software upgrades would require
    recertification, and the manufacturers of such systems do not always
    recertify their platforms with the latest operating systems.
  * Some embedded systems either do not have provision for firmware
    upgrades and/or are operated on disconnected networks so that
    upgrades are cumbersome (and may violate company security policies);
    those products sometimes do not have the option of firmware updates
    because there is no revenue stream to support them and they wouldn't
    be used anyway.  And yet, it's common for embedded systems to be
    configured, queried, or monitored using HTTP[S].
  * I have also worked on products for manufacturing environments for
    which upgrades were forbidden; any firmware upgrade would have
    required shutting down the assembly line for days and retesting the
    whole thing.
  * Finally, sometimes software or firmware "upgrades" take away
    functionality present in earlier versions, so that the "upgrade" may
    make that computer useless for its intended purpose.

In general, there are two kinds of problems caused by disabling of TLS 
1.0/1.1 in implementations:

1. Old clients cannot talk to newer servers

Again, sometimes clients run on old machines that cannot be upgraded or 
replaced.   When servers refuse to support old TLS versions, an old 
client may refuse to work at all.   It is not always feasible to 
download the same file from a different machine or different client program.

I have seen this happen when trying to upgrade some software on an old 
MacBook Pro.   The software I was trying to download could only be 
downloaded from Apple using Safari on a Mac. Apple's server would not 
use a version of TLS compatible with the old version of Safari I had, 
and there were no upgrades to that version of Safari.  I tried 
downloading the software from another (non-Apple) computer; the server 
would not let me do so.   I didn't have a more current Mac to use, 
didn't wish to buy one, and the pandemic made using someone else's Mac 

The best idea I came up with was to set up a web proxy that supported 
more recent versions of TLS, and configure Safari to communicate via 
that web proxy.   But I never found time to do that.

I'm not saying the RFC should be fixed for me, but rather, that I've 
personally experienced a situation that many other people undoubtedly 
have experienced and will experience after publication of this RFC.  
(Some servers are already following these recommendations.)

I have also worked with systems operated by a major petroleum producer 
(who will remain unamed) who had (unsurprisingly) very elaborate 
security measures.   Their internal networks were inaccessible from 
outside systems except via multiple layers of remote desktop.  So any 
client software to be used had to be software already vetted and 
installed on their internal machines.   But presumably because of the 
difficulty of vetting new software, the only browser available was MSIE 
5 [don't remember which version of Windows].   (I know this because I 
had to update product software to use GIF files instead of PNG, add some 
JS polyfills, and avoid some HTML5 features, in order to be compatible 
with their browsers).   I cite this only as another example that one 
cannot reasonably expect all client and server to be current, or even 
nearly so.

In some of these cases (when the client cannot be upgraded) an 
appropriate remedy may be to install a web proxy to allow the old client 
to communicate with the server.   Of course this can still come with 
risks, including perhaps exposure of the network traffic between the 
client and the web proxy.

In other cases, server operators might do well to consider whether, for 
their specific users, services, and content, TLS >= 1.2  is really an 
appropriate constraint to impose.   For example the web server 
is currently supporting older versions of TLS in order to make IETF 
documents as widely available as possible, even on legacy systems.  IMO, 
that practice makes sense given IETF's mission and the fact that all of 
the documents on that server are intended to be publicly available.

(though if other services besides document download are provided on the 
same server, particularly if they use password-over-TLS authentication, 
either requiring a higher version of TLS for those services, or hosting 
those services on a different server that does require >= TLS 1.2, might 
make good sense)

2. Newer clients cannot talk to old servers

Perhaps naively, I assume that most servers reachable via the public 
Internet are upgradeable, and can/should be upgraded to support at least 
TLS 1.2.  Certainly I would recommend against exposing any server to the 
public Internet, for which security upgrades are not routinely 
provided.   So I'm /not/ talking about those servers here.

My concern here is with embedded systems that support HTTPS for 
configuration, monitoring, or control of industrial hardware. The 
security concerns are both very real (monitoring/controlling vital 
manufacturing or infrastructure and/or with potential risk to human 
lives) and often (unfortunately) not given proper regard.   Frankly, 
most operators of such systems probably use (non-TLS) HTTP or other 
cleartext interfaces to configure, monitor, and/or control such devices, 
and rely on the illusion of a completely disconnected network to let 
them sleep at night.   But some of those embedded devices do support 
TLS, even if it's old TLS (likely with self-signed certs... TLS really 
wasn't designed to work with embedded systems that don't have DNS 
names.)   Again, upgrades may be unavailable, or infeasible, for many of 
these embedded devices.

Client programs in such environments may be a mixture of web browsers 
and/or dedicated special-purpose clients (which may be interactive or 
non-interactive) or proxies (e.g. to adapt a proprietary interface to 
something like OPC-UA).   If the client can just keep using old systems 
with old web browsers, they can keep using those browsers to 
control/configure/monitor those embedded devices, but if the client 
system is replaced with newer hardware and a newer OS and browser, this 
may fail.   For special-purpose clients the situation is slightly 
different - the vendors of those clients will presumably be aware of the 
limitations of the embedded systems they talk to - but deprecating TLS 
1.0 and 1.1 from libraries may make support more difficult.

For newer interactive clients I believe the appropriate action when 
talking to a server that doesn't support TLS >= 1.2 is to (a) warn the 
user, and (b) treat the connection as if it were insecure.  (so no 
"lock" icon, for example, and the usual warnings about submitting 
information over an insecure channel.)

For newer non-interactive clients an appropriate action might be to 
permit the client to refuse TLS < 1.2 by default but be explicitly 
configurable to use earlier versions.

For web browsers, the use of browser plugins might permit the occasional 
use of TLS < 1.2 (since most users won't need it) without the increased 
attack surface for every user.   A web proxy might also work as a 
solution for web browsers and some other http clients.

3.  Fixes to the draft

I believe the draft needs to explicitly discuss some of these cases, and 
suggest workarounds for such cases, rather than simply say "MUST NOT".   
IMO the best result from saying "MUST NOT" is that IETF security 
documents will be more likely to be disregarded since they're making 
poor recommendations for many cases.   That's not good, but worse 
results are also possible, including that the effect of these 
recommendations will be to actually reduce security for many operations, 
at least in the short term.

I realize that "MUST NOT" is attractive because it is simple and clear 
language, and that "SHOULD NOT" (even though it's the right language per 
2119 definitions) may be seen as allowing too much weasel room.   I'm 
not sure how best to address that. "MUST NOT... except..." could also be 
confusing.   Saying "MUST NOT" but also discussing exceptions in the 
document may be seen as conflicting or confusing.   I don't have a 
strong opinion about how to resolve that dilemma, but I do think some 
exceptional cases should be acknowledged somehow.   (or maybe in a 
separate RFC?)

There are probably other cases that I haven't considered.  It's easy to 
make the mistake of assuming that every application that uses TLS is 
like the web (e.g. interactive), but of course that's not the case.    
The Right Thing to do for an SMTP client relaying mail, for example, is 
probably to use the highest TLS version supported by the server, rather 
than disconnect the SMTP session and resend the message as cleartext.    
Even SSL 1.0 seems better than cleartext in that case.   Of course, the 
client could bounce the message, but given that the common expectation 
is that mail will be relayed in cleartext if necessary, bouncing seems 
like the Wrong Thing to do absent an originator-specified requirement 
for hop-by-hop encryption.

Similarly if a user is trying to read his/her mail from an old mobile 
phone, should that user's ability to read mail cease to work because the 
mail server now requires TLS 1.2 or better? Old phones don't necessarily 
have upgrades available.   And while a lot of cellular networks actively 
encourage upgrading of old phones by pessimizing their service (newer 
phones may make better use of radio bandwidth and/or support more 
frequencies), I am not in a position to say what works for the entire 
world. I have heard that old phones are still usable, and in demand, in 
many countries.

4.  Future

This is out of scope for this draft, but I also believe that these kinds 
of compatibility issues may need to be analyzed every time the IETF 
recommends to deprecate something.