Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Eric Rescorla <ekr@rtfm.com> Sat, 28 November 2020 04:31 UTC
Return-Path: <ekr@rtfm.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 A9D343A0EC2 for <tls@ietfa.amsl.com>; Fri, 27 Nov 2020 20:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 OkyOr4xzSL0Z for <tls@ietfa.amsl.com>; Fri, 27 Nov 2020 20:31:34 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92453A0E46 for <tls@ietf.org>; Fri, 27 Nov 2020 20:31:33 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id y10so8153259ljc.7 for <tls@ietf.org>; Fri, 27 Nov 2020 20:31:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c9WKmUrgFHxCJI6e1GLytI1UHgwF61V1Y+2kVZ8e2g4=; b=aMww25O9niS8idaFOA122aMzd2Sl4+uoLl+1Dp6dm/N7JOxkx88SmJAyaU1ZpSC6dp 0LJAoCyW3ndNilAvN9W8BMoyfDS6QIwX6FfiQ4vTw462SMAivY0HLNjdkmThOeFJDp+7 OHJK59vzlp7DJH04TpTTEYYUk7qe5s2kKqmq7+U/ur/YlhECFELAstNhd4Ebh6ikzaiR BHukln+hZ1KzhFp59gKGQ5mVrN4ey1Yh5XEyIUK+o0F78RtgrdwNwmMeRw1ssodrciuJ RtANIP6Xk7jC0E4BGs5owQqJN7jSBOuZo4BLv6w2sqFGrcebqNnvNJ0h0yvdTFFXc52X ZZGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c9WKmUrgFHxCJI6e1GLytI1UHgwF61V1Y+2kVZ8e2g4=; b=VNWllCHOxeR1/5vzwrh5kbcvjjPW6cwtMNiR+qVY05d48AH/nOkHo5wzEuL1ptIEny U+ycUrutt8bM1/V53P9OBamyMa1dRcDpoxPxAkNdiau024oqcOpMRNEfdeN8/INaHLhg QDjSYT1nvcJEbJVV4WbuZt1x/WGbw+z6fmRJqWd/c/d/Gy8hYLLEysRwnLa7ch78Ry2F bbdR1NH8X26cz3kdV/6skHad3SbkqcNGI1Oi5J+pz6F/5a8F2mz1BC+NGaVCpH7iY9GE /NtLvvxRBoeTdf0gMzBGZD6edf8Hb86+NGXMiVgrv5ULT3KeETJpZe63E5R5UfmYW8Qb kJJQ==
X-Gm-Message-State: AOAM533NnMx9AGiubyoPzc87r/tpKi46pNiSjFm/uY2hx7nJs5O/dOCB Xc2abptRatCEVxTOO9X2E/P8RtY1Tm6HXum8IEcRJA==
X-Google-Smtp-Source: ABdhPJw2xq3sP1NU1POrWzGZjgGHCU6PPeYAMX+PI57nRhbbQi2bRqWh0z+fXEKO3fYZshL3pm9AR4yBJ2gJGSkLI5Q=
X-Received: by 2002:a2e:9707:: with SMTP id r7mr4847044lji.265.1606537891717; Fri, 27 Nov 2020 20:31:31 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <584c7749-6986-0329-873c-2d1ff8b55251@network-heretics.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 27 Nov 2020 20:30:55 -0800
Message-ID: <CABcZeBNmzSV38Hm+cpas=hAO3RvV2V6nCkRUM2NkBM8mG7bdBg@mail.gmail.com>
To: Keith Moore <moore@network-heretics.com>
Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate@ietf.org, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ab89305b5234072"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QPuqepUgln0Y3m8MpUBn4nEXzug>
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:31:38 -0000
Hi Keith, Thanks for your note. I think it's clear we see things differently, and I don't think it's that useful to get into an extended back and forth on those points. Accordingly I've done a fair bit of trimming to focus on the points where I think you may have misunderstood me (perhaps due to unclear writing on my part). On Fri, Nov 27, 2020 at 7:39 PM Keith Moore <moore@network-heretics.com> wrote: > On 11/27/20 9:53 PM, Eric Rescorla wrote: > > This > > would be true in any case, but is doubly true in the case of COMSEC > > protocols: What we want is to be able to guarantee a certain mimimal > > level of security if you're using TLS, but having weaker versions in > > play makes that hard, and not just for the un-upgraded people because > > we need to worry about downgrade attacks. > > This sort of sounds like a marketing argument. Yes, in some sense we'd > like for "TLS" to mean "you're secure, you don't have to think about it" > but more realistically TLS 1.0, 1.1, 1.2, and 1.3 each provide different > countermeasures against attack (and in some cases, different drawbacks, > like TLS 1.3 + ESNI being blocked) and you probably do need to be aware > of those differences. 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. > > > 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.) > > > > This is not correct. TLS takes no position at all on how servers > > are authenticated. It merely assumes that there is some way to > > validate the certificate and outsources the details to application > > bindings. For instance, you could have an IP address cert. > > 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 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: * Browsers block active "mixed content": JavaScript from http origins loaded into an https origin. In the scenario you posit where we treat https from TLS 1.1 as "insecure", then if the target server for some reason gets configured as TLS 1.1, then the client would have to block it, creating breakage * Cookies can be set to be secure only. Here again, if you have a situation in which some of your servers support TLS 1.2 and others TLS 1.1, then you can get breakage where cookies are not sent. > 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. -Ekr [0] For instance: https://www.usenix.org/legacy/events/sec09/tech/full_papers/sunshine.pdf
- [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