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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 28 November 2020 15:22 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 D8F513A074B; Sat, 28 Nov 2020 07:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 s9fMqtTd1KTI; Sat, 28 Nov 2020 07:22:23 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B812B3A0640; Sat, 28 Nov 2020 07:22:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90074BE3E; Sat, 28 Nov 2020 15:22:19 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC57bswmN36A; Sat, 28 Nov 2020 15:22:16 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3D4DFBE2F; Sat, 28 Nov 2020 15:22:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1606576936; bh=NDDCN+nR3nHVDGCdP49Ak7tnJnCgTYIg8uE8NyWENv4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iRZpmUnWsv1BgrMHuY1wq/SsuAUeqh6OUvkrIuuwv6WiEJr+TTLQXOthVJKIWolo2 bewpv9Co0jUEkxU0dSD7TB60ZwoPEdEyT32KAc5BLhjgAQFFhMKFOjF7xtEyoB+XPb maaGKg70dgDchTaMnir64DOcnsZi2PzfgOA0QdoY=
To: Keith Moore <moore@network-heretics.com>, last-call@ietf.org
Cc: draft-ietf-tls-oldversions-deprecate@ietf.org, tls-chairs@ietf.org, tls@ietf.org
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <b5314e17-645a-22ea-3ce9-78f208630ae1@cs.tcd.ie>
Date: Sat, 28 Nov 2020 15:22:15 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="BxlIKIjMeN58oPahW6Js1x1D52UsxgLIx"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nP-DjLyYrUUSfuqA06JS_xFmjkU>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-BeenThere: tls@ietf.org
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." <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: Sat, 28 Nov 2020 15:22:26 -0000

Hi Keith,

In general I agree with Ekr's position on this (not a
surprise as a co-author I guess:-) so I won't repeat
arguments. I do have one question below though that
wasn't yet touched upon...

On 28/11/2020 00:44, Keith Moore wrote:
> 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 earlier iterations of the draft we included some survey
results for TLS version usage in web, mail and OSes. I think
your argument to special-case embedded systems or systems
without s/w update would be a lot stronger if you or someone
else had data to offer about the prevalence of these systems
and the TLS versions they support. I realise that sometimes
people can't name product versions (but then sometimes one
can!) or be very precise about deployments but people have
figured out ways to measure these things in other contexts.
(Note: I said "stronger" above - I'm not dismissing your
point due to the current lack of concrete data.)

Cheers,
S.

> 
> 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 
> infeasible.
> 
> 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 ietf.org 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.
> 
> 
> Keith
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>