As the TLS 1.3 standardization process (hopefully) comes to a close, there has been some drama on the TLS WG mailing list and at the recent IETF 99 meeting in Prague regarding the use of TLS 1.3 in enterprise networks. This is a surprisingly contentious and important topic that I suspect many people who don’t follow protocol development closely may have missed. Below, I’m going to try to describe the various points of view from a (mostly) nontechnical perspective and the arguments that have been advanced. Then, I’ll briefly conclude with my thoughts on the topic.
IETF, TLS, WG, what are those?
Transport Layer Security (TLS) is, without exaggeration, the most important security protocol in use on the Internet today. It is the successor protocol to the older SSL protocol and is used to cryptographically protect a wide variety of Internet communication including online banking, (a significant fraction of) email traffic, more than half of all web browsing, and an ever-increasing amount of normal Internet activity.
TLS is standardized by the Internet Engineering Task Force (IETF) which is organized into a set of working groups (WGs). Each working group has a charter which describes its mission. The TLS WG is currently charged with designing the fourth iteration of the TLS protocol, TLS 1.3. This multi-year process takes place primarily on the TLS mailing list as well as in regular, in-person meetings. The 99th IETF meeting just concluded.
Sounds pretty dry, what’s the drama about?
Much of the work is pretty dry and technical. One of the WG’s goals for TLS 1.3 is to produce a more secure protocol than prior versions which have had a series of subtle problems. To that end, the WG has removed a number of cryptographic options that reduced the security. This includes removing options like ciphersuites (sets of cryptographic algorithms that work together to secure the traffic) that do not provide forward secrecy.
To quote Wikipedia, “A public-key system has the property of forward secrecy if it generates one random secret key per session to complete a key agreement, without using a deterministic algorithm. This means that the compromise of one message cannot compromise others as well, and there is no one secret value whose acquisition would compromise multiple messages.” Forward secrecy also generally requires the session key to be destroyed once the session ends to prevent an adversary from decrypting traffic afterward.
Forward secrecy is a very desirable property in a cryptosystem. As I recall, when removing the non-forward-secret ciphersuites was proposed on the mailing list, there was broad consensus.
At some point, late into the TLS 1.3 design process, some enterprise network operators began to realize that this would reduce their ability to inspect traffic in order to troubleshoot problems within their networks and started asking the TLS WG to restore some of the removed ciphersuites or provide some other mechanism to support their internal network requirements. (The most recently proposed mechanism uses what’s called static Diffie–Hellman and works by reusing encryption keys. Interestingly, a form of this is used today as a minor optimization and isn’t technically forbidden by TLS 1.3.)
Initially, the WG refused to consider any proposal which would hurt or remove forward secrecy. Recently, as the TLS 1.3 standardization effort has begun to draw to a close, the enterprise network operators have become more vocal. On the mailing list and at the in-person meetings, three viewpoints have emerged. The debate between those with conflicting points of view has been vigorous and, in terms of the sheer number of words written, quite lengthy.
What, exactly, do the enterprise folks want?
In a nutshell, these network operators want the ability to decrypt the traffic that is inside their own networks. Let’s call this the enterprise viewpoint. Now keep in mind, any network traffic that is inside their network was either (a) generated from inside their network in which case the enterprise’s own computers created the plaintext in the first place; or (b) the traffic was sent from the Internet to one of the enterprise’s computers. In either case, they already have the ability to do whatever they want with the plaintext, including storing all of it and examining it at will.
If they already have access to the plaintext, why do they need changes to TLS 1.3 to enable them to get plaintext?
This question is key to the whole debate. The enterprise viewpoint holds that operators need to be able to decrypt traffic from packet captures from various vantage points within the network. For example, they would like to decrypt traffic before and after a load balancer, web server, or database server in order to pinpoint which part of the network infrastructure is causing problems. On the mailing list and in person, they have been adamant that decryption from package capture (rather than, say, endpoint logging) is the only way they can perform this sort of network debugging at the scale they need given the fragility of what appear to be mind-bogglingly complex network architectures.
It seems pretty reasonable to support this usecase. What’s the problem with accommodating their request? After all, this will only be for use inside their own networks.
On the one hand, this is reasonable and is completely supported today using TLS 1.2. (Indeed, one of the suggestions has been for network operators to continue using TLS 1.2 inside their networks if they need this capability.) On the other hand, there’s no technical way to confine proposals to enable decryption to a particular network or data center.
There are two major concerns raised by those opposed to breaking or degrading forward secrecy. Let’s call this the forward-secret viewpoint. One concern raised by those with the forward-secret viewpoint is that proposals such as the static Diffie–Hellman approach mentioned above will enable wiretapping which would violate the IETF’s Policy on Wiretapping. Although that may be true (and this is hotly contested), some other technical mechanisms have been proposed that would make such wiretapping externally visible.
The second concern is both more subtle and, I think, more compelling. TLS (and SSL before it) has a history of supporting weak cryptography and this support has come back to bite us several times. The best of example of this is the export ciphersuites. These used cryptographically weak algorithms but were, at one point in time, the only ciphersuites that could be legally exported from the US. Two decades after the use of export ciphersuites should have ended, researchers showed how to abuse support for these deprecated algorithms in modern TLS libraries to man-in-the-middle TLS connections.
The forward-secret viewpoint holds that the TLS WG should not standardize any weaker form of TLS and if this makes some network operators’ jobs harder, then so be it.
That’s two viewpoints—enterprise and forward-secret—what’s the third?
Let’s call the third viewpoint, the pragmatic viewpoint. This viewpoint holds that whether or not enterprise network operators really need the decryption capability, some of them really want it. And since they really want it, they’re going to do something to get it. It’s strictly better for the mechanism to be designed in public, following normal IETF procedures, than to be cobbled together by people whose focus is on operations and not, necessarily, on security. It’s worth noting that at least one of the authors of the static Diffie–Hellman proposal mentioned above firmly holds the pragmatic viewpoint.
Which viewpoint is correct?
Before I say which viewpoint I think makes the strongest case, I want to point out that I’m sympathetic to all three viewpoints. The network operator’s job is not an easy one (or so I assume; it’s definitely outside my particular area of expertise). If they say they need plaintext in order to do their job, I don’t think I’m in a position to contradict them..
The pragmatic viewpoint is quite compelling. All else being equal, I’d much rather have the IETF design a standard mechanism to support the network operators’ needs than have a hodgepodge of home-grown, difficult to use, noninteroperable, and potentially insecure solutions.
But, as they say, all else is rarely equal. The Internet is for End Users, not for network operators. The protocols we design today will, for better or for worse, be in use for decades. End-users have been paying the price for our mistakes and past compromises on security. As protocol and implementation deficiencies necessitate new network hardware and software, the network operators have paid their own price.
To rebut the enterprise and pragmatic viewpoints, I need not take a security-maximalist view. The sense of urgency from the operators and the pragmatists is, I believe, unwarranted. Yes, switching to TLS 1.3 will prevent operators from doing precisely what they’re doing today; however, there is currently no need to switch. TLS 1.2 supports their usecase and TLS 1.2, when used correctly, is secure as far as we know. Of course the network operators won’t receive the benefits of mandatory forward secrecy, but that is precisely what they are asking to give up in TLS 1.3.
Designing secure protocols is hard. To date, our best efforts have not been as successful as we would like. In my view, the only option we have is to design the most secure protocols we can to achieve our stated objectives. We may still get it wrong, of course. My hope is that in 20 years, we won’t, once again, be dealing with security issues we know about today. Instead, I hope we’ll be dealing with a whole new set of security issues.
I want to thank Cynthia Taylor and Joseph Lorenzo Hall for providing helpful comments on a draft of this post and helping me clarify my arguments.