Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Keith Moore <moore@network-heretics.com> Sat, 28 November 2020 04:43 UTC
Return-Path: <moore@network-heretics.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 E5EB93A0E9E; Fri, 27 Nov 2020 20:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 EhUzWPy5BTuw; Fri, 27 Nov 2020 20:43:46 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAD73A0E46; Fri, 27 Nov 2020 20:43:45 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CE27F5C0129; Fri, 27 Nov 2020 23:43:44 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 27 Nov 2020 23:43:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=ROMCCvunvBCrKNFi2iZbT2nSH7Zi8Xr1VLofOcCKJ mU=; b=cxxXX0IAQpWjcQIct5ZwxdGbVbJg1pCmG/vfpKb4i9ZlMdRMIEHw8Pf/W uiDUVVV/b/ymQTutX0UNtocvQcgE/0n3fyej//LhlQX2TLBiVrbxtkb/z+Y8ceCY +SlPCtnC4amCjIO48+6vcKaO5noZmENqJ3EV8f/B9RibcmYOfhB7v8FtCF5NexVy /8oUL7B6ERxuOHF0R9i0/lB43saZuXqHhdB8Dexsmhf0rWH1iGKAgNUsiWs+X3DU 4q5cuyuMdRu1+PrTYjIZGbO+l0Idx++HYDUVLDL0zp/0yJ6KcsgLqpf1TZ/ZhlHq s3vOdWwmi2SE/vEkKv56TUIZPpOHA==
X-ME-Sender: <xms:f9XBX0WqX60XyFthC9S2-_5BOVxilZAa5uRGXn2I-lX_Iqys2UzpMg> <xme:f9XBX4mZR9pDkSKeSUruiyWWXmIqfaWa8T01Yk-Ek2kee4PvqHhqtV4WBL9dTyw16 euss1FjgBb1VA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehhedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeevuddtveejhe dttdejteeggfelgfehgeffueejjeetveehffekuedvvdfhleehvdenucffohhmrghinhep hhhtthhpshgtohhnthgvnhhtihhsthhrvggrthgvughthhgvshgrmhgvnhhomhgrthhtvg hrfihhihgthhhvvghrshhiohhnohhfthhlshhithhushgvshdrihhnpdhinhgrfhhivghl uggrnhgurghsshhumhgvthhhrghtthhhvggtohhnnhgvtghtihhonhhishhsvggtuhhrvg drihhnnecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvg hrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:f9XBX4bNGZTn5ANKrdHys_i-z0NKTQl6mgAlfrQvf3AY8CPGov6kWQ> <xmx:f9XBXzVSDi5itRshAnUlXChaaUZCD6sM1e3qMfELRPV2LJaS7mF6ZQ> <xmx:f9XBX-liFHUSD03gZoJepMW-juqsOJafu_V0aJrhVk8SYaD-Hgoiew> <xmx:gNXBXyuP57zygsOq7yuZAXMdFxjfgI-XzztstrE0KJFUfE91Bdjzjw>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id EAE283280060; Fri, 27 Nov 2020 23:43:42 -0500 (EST)
To: Eric Rescorla <ekr@rtfm.com>
Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate@ietf.org, tls-chairs <tls-chairs@ietf.org>, tls@ietf.org
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com> <CABcZeBPCccfDuGyZC-y88-dapjWYy57YRWWK3vsFOGM5Bxa+8Q@mail.gmail.com> <584c7749-6986-0329-873c-2d1ff8b55251@network-heretics.com> <CABcZeBNmzSV38Hm+cpas=hAO3RvV2V6nCkRUM2NkBM8mG7bdBg@mail.gmail.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <7e1af512-ba45-5d9a-6538-518179ab2c3a@network-heretics.com>
Date: Fri, 27 Nov 2020 23:43:42 -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: <CABcZeBNmzSV38Hm+cpas=hAO3RvV2V6nCkRUM2NkBM8mG7bdBg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4VT4Kfwk4ZwnYMAwhH1_RgO2Oxc>
Subject: Re: [TLS] [Last-Call] 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 04:43:48 -0000
On 11/27/20 11:30 PM, Eric Rescorla wrote: > > Well, I can't speak to how it sounds to you, but it's not a marketing > argument but rather a security one. This is easiest to understand in > the context of the Web, where you have a reference that contains one > bit: http versus https,and all https content is treated the same, no > matter which version of TLS it uses. In that context, having all the > supported versions meet some minimum set of security properties is > quite helpful. It's true that TLS 1.0, 1.1, 1.2,and 1.3 have different > properties, which is precisely why it's desirable to disable versions > below 1.2 so that the properties are more consistent. Sure, it would be great if users and operators never had to worry about old TLS versions. But in practice, they do, for reasons already mentioned. It's simply not feasible to upgrade or discard everything using old versions of TLS in the next few years, and a lot of those hosts and devices and programs will continue to need to be used for a variety of valid reasons. Pretending otherwise for the sake of an unrealistically simple statement of security policy seems unhelpful. > > > That's technically correct of course, but I think you know what I > > mean. Without a reliable way of knowing that the server's certificate > > is signed by a trusted party, the connection is vulnerable to an MITM > > attack. And the only widely implemented reliable way of doing that > > is to use well-known and widely trusted CAs. > > Yes, and those certificates can contain IP addresses. Not all > public CAs issue them, but some do. I'm aware of that. But what really is the point of a cert (especially one issued by a public CA) that has an RFC1918 address as its subject? Not that it matters that much because the vast majority of sites using embedded systems aren't going to bother with them. Most of those systems probably don't support cert installation by customers anyway. > > > > > I'm not sure what clients you're talking about, but for the clients > > > I am aware of, this would be somewhere between a broken experience > > > and an anti-pattern. For example, in Web clients, because the origin > > > includes the scheme, treating https:// URIs as http:// URIs will have > > > all sorts of negative side effects, such as making cookies unavailable > > > etc. For non-Web clients such as email and calendar, having any > > > kind of overridable warning increases the risk that people will > > > click through those warnings and expose their sensitive information > > > such as passwords, which is why many clients are moving away from > > > this kind of UI. > > UI design is a tricky art, and I agree that some users might see (or > > type) https:// in a field and assume that the connection is secure. > > In the Web context this is not primarily a UI issue; web client > security mostly does not rely on the user looking at the URL (and in > fact many clients, especially mobile ones, conceal the URL). Rather, > they automatically enforce partitioning between insecure (http) and > secure (https) contexts, and therefore having a context which is > neither secure nor insecurecreates real challenges. Let me give you > two examples: To clarify, my suggestion was that https with TLS < 1.2 be treated as insecure, not as neither secure nor insecure or any kind of "in between". (and yes, I was ware of that kind of partitioning) > > But I think it's possible for UI designs to be more informative and > less > > likely to be misunderstood, if the designers understand why it's > > important. I also think that IETF is on thin ice if we think we're > > in a better position than UI designers to decide what effectively > > informs users and allows them to make effective choices, across all > > devices and use cases. > > I'm not suggesting that the IETF design UI. > > We're getting pretty far into the weeds here, but I can tell you is > that the general trend in this area -- especially in browsers but also > in some mail and calendar clients -- is to simply present an error and > to make overriding that error difficult if not impossible. This is > informed by a body of research [0] that indicates that users are too > willing to override these warnings even in dangerous settings. Yes, I'm aware of that too. You should probably be aware that one effect of this that I've seen affect actual products, is to avoid supporting TLS in embedded systems. Keith
- [TLS] Last Call: <draft-ietf-tls-oldversions-depr… The IESG
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… tom petch
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Sean Turner
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Gary Gapinski
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eric Rescorla
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Eliot Lear
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Lamb
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Martin Duke
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Peter Gutmann
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Viktor Dukhovni
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ben Smyth
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Olle E. Johansson
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Keith Moore
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Salz, Rich
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Bill Frantz
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Joe Abley
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Eliot Lear
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Gary Gapinski
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Watson Ladd
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… STARK, BARBARA H
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… BRUNGARD, DEBORAH A
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… BRUNGARD, DEBORAH A
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Andrew Campling
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ackermann, Michael
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Hilliard
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Ted Lemon
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Rob Sayre
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Nick Hilliard
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Christian de Larrinaga
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Kathleen Moriarty
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Peter Gutmann
- [TLS] Results of Last Call: <draft-ietf-tls-oldve… Benjamin Kaduk
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Gary Gapinski
- Re: [TLS] Last Call: <draft-ietf-tls-oldversions-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… Stephen Farrell
- Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-… tom petch