Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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 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 documen
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 11/27/20 9:53 PM, Eric Rescorla wrote: Keith, Thanks for your note. Most of the general points you raise here were discussed when the TLS WG decided to move forward with this draft [0], though perhaps some of that is not reflected in the text. Of course that doesn't make this points invalid, so I'll try to summarize my view of the rationale here. Your primary objection seems to be this has the effect of creating interop problems for older implementations that are unable to upgrade. This is of course true, however I think there are a number of factors that outweight that. First, while certainly is problematic that people who have un-upgraded endpoints will find they cannot connect to modern endpoints, we have to ask what is best for the ecosystem as a whole, and IMO what is best for that ecosystem is to upgrade to modern protocols. If you're going to try to state what's best for the ecosystem as a whole, you need to understand that "the ecosystem" (or at least, the set of hosts and protocols using TLS) is a lot more diverse than things that are connected to the Internet most of the time, well-supported, and easily upgraded. The idea that everybody should be constantly upgraded has not been shown to be workable, and there are reasons to believe that it is not workable. When you give advice that is unworkable because it is based on dubious assumptions, you might not only cause interoperability failures, you might end up degrading security in very important cases. 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. While we have made efforts to protect against downgrade, the number of separate interacting versions makes this very difficult to analyze and ensure, and so the fewer versions in play the easier this is. Asking everyone else to bear these costs in terms of risk, management, complexity, etc. so that a few people don't have to upgrade seems like the wrong tradeoff. I don't think it's a matter of "asking everyone else to bear these costs". I think TLS < 1.2 should be disabled in the vast majority of clients, and in many (probably not all) public facing servers, but some users and operators will need to have workarounds to deal with implementations for which near-term upgrades (say, for the next 5-10 years) are infeasible. Second, it's not clear to me that we're doing the people who have un-upgraded endpoints any favors by continuing to allow old versions of TLS. As a practical matter any piece of software which is so old that it does not support TLS 1.2 quite likely has a number of security defects (whether in the TLS stack or elsewhere) that make it quite hazardous to connect to any network which might have attackers on it, which, as RFC 3552 reminds us, is any network. Obviously, people have to set their own risk level, but that doesn't mean that we have to endorse everything they want to do. Yes, but you might actually increase the vulnerability by insisting that they not use the only TLS versions that are available to them. There's a lot of Bad Ideas floating around about what makes things secure, and a lot of Bad Security Policy that derives from those Bad Ideas. But practically speaking, you can't change those Bad Ideas and Bad Policies overnight without likely making them much worse. People have to actually understand what they're doing first, and that takes time. And there are a lot of things that have to get fixed besides just the TLS versions to make some of these environments more secure. Lots of people having to make security-related decisions simply haven't managed to deal with the complexity of the tradeoffs, so it's really common to hear handwaving arguments of the form "the only threat we need to consider is X, and Y will deal with that threat". And of course that's not anywhere nearly true, and Y is woefully insufficient. None of which is a surprise to you, I'm sure. Personally I often ask myself "what does it take to get devices in the field regularly upgraded?" And it's not a simple answer. First thing that's needed is an ongoing revenue stream to provide those upgrades in the first place, and there's a huge amount of intertia/mindshare to be overcome just for that. Second thing is you have to keep device vendor corporate overlords from repurposing that money
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 11/27/20 11:58 PM, Eric Rescorla wrote: 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". Well, the problem is that it is secure from the perspective of the site author but insecure from the perspective of the client. That's not going to end well for the reasons I indicated above. Well that is an interesting point that I missed earlier. But I think the situation will be the same if any of the obvious workarounds is used, like a plugin or proxy. Keith ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 11/30/20 7:29 PM, Peter Gutmann wrote: So I think the text should include wording to the effect that it applies to public Internet use but not to embedded/SCADA/etc for which very different considerations apply. I've been thinking something like this also. But IMO there are still valid cases for negotiating older versions of TLS on the public Internet, such as the mail relaying case mentioned earlier. So far I haven't thought of a reason where either (a) bouncing an email message; (b) resending it in cleartext; or (c) discarding it, is better than relaying with TLS 1.0 or 1.1. (Though maybe there aren't enough MTAs that do opportunistic TLS using version <= 1.1 to matter.) More generally, the right remedial behavior for an application with e2e connectivity and an interactive UI that can't do better than TLS 1.1, isn't necessarily the right behavior for all applications. So maybe two restrictions on scope? (1) public Internet; (2) e2e and interactive application? But it's important to understand that protocols and protocol implementations that are used on the public Internet are also used on isolated and mostly-isolated networks. Given that this is BCP and not standards-track, maybe it should just be made clear that an implementation that does support 1.0 or 1.1 isn't necessarily violating the standard, it's just discouraged as a practice. Keith ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 12/1/20 4:29 AM, Peter Gutmann wrote: I think all it needs is something along the lines of "This BCP applies to TLS as used on the public Internet [Not part of the text but meaning the area that the IETF creates standards for]. Not specifically relevant to this draft, but: Is it actually defined anywhere that IETF standards only apply to the public Internet? IMO IETF needs to realize that implementations of its standards are used outside of the public Internet and consider that when writing its documents. (even though different rules may be appropriate on private and mostly-isolated networks) Keith p.s. I keep thinking that this "MUST NOT TLS < 1.2" recommendation is like a public health recommendation, one that is worded over-simply to try to make it have maximum useful effect but perhaps to the point of being misleading or even harmful. e.g. "You MUST wear masks to reduce the spread of COVID-19", but not saying "oh yeah, if you're outdoors and not around other people you're probably fine without a mask" and "masks are pointless if you only wear them over your mouths or chins", and "the masks that have valves in them to allow exhaled breath to exit unimpeded are also useless for this purpose" and "you need to wear them when indoors and around co-workers, not merely when customers or visitors are present". At least where I live I see so many people using masks in ineffective ways that I don't think the simple recommendation is working, though I'm not sure that a more detailed recommendation would work better. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 12/2/20 5:37 AM, Peter Gutmann wrote: If a device can be at all critical (and even if it isn’t), then it should be upgraded or replaced. The fact that many of these devices are extremely critical is precisely why they're never replaced or upgraded, because they can't be taken out of production. +1 Another problem is that "upgrades" often don't function identically to the firmware or equipment it would be replacing, making replacement inherently disruptive even if it didn't require a shutdown. Under current conditions, relying on upgrades to fix security issues in industrial environments is a nonstarter. There's a tremendous amount of inertia to overcome at many different levels. Keith ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
