Do You Need to Implement TLS 1.3 Right Now?

No, you don’t need to implement TLS 1.3 right now. (Shortest blog post ever.)
But if you're curious why not, keep reading!

TLS 1.3 is a great step. A natural progression. An obvious upgrade over TLS 1.2. It’s 0.1 better, after all!

It’s also overrated, aggravating, and much ado about - well, very little, depending on who you ask.

At the International Cryptographic Module Conference in Vancouver this spring, a panel was moderated by Tim Hudson (of OpenSSL and Cryptsoft) and featuring Matt Caswell (OpenSSL), Brent Cook (LibreSSL), Chris Conlon (WolfSSL), and David Hook (Bouncy Castle). It had been scheduled in conflict with a very popular session and was relegated to a smaller room away from the main lecture hall. I made sure to attend anyway, and I was not disappointed. The quality of the discussion and the candor of the panelists was eye-opening.

Hudson kicked off the slide deck with a Cloudflare analysis of TLS deployments in the wild. The slide showed a pie chart with 74% of connections still made using TLS 1.2, while 21% had upgraded to 1.3. OpenSSL’s Caswell began the conversation by noting that there was no need to rush into the transition, let alone panic, while Bouncy Castle’s Hook noted skepticism that the connections reported as TLS 1.3 in production deployment were actually TLS 1.3. These first two comments really set the tone for the session.

LibreSSL’s Cook took a minute to interject that TLS 1.2 configurations today are actually quite strong. He continued to describe that while five years ago, vulnerabilities may have been a concern, today’s TLS 1.2 has already been fortified and he believes 1.3 to be only marginally better, if at all. He asked the audience “who really wants 1.3 to succeed?” before suggesting that it might be Google advancing the narrative as much as anyone else. He also suggested mobile corporations could be a winner from expanded TLS 1.3 usage, as they would benefit from higher latency. An audience member posited that browsers benefit, specifically from protecting their ad revenue from MITM attacks. Not exactly the altruistic beneficiaries that may have been imagined.

Tim Hudson and Matt Caswell, teammates on OpenSSL, went on to agree that TLS 1.3 provides forced configurations that reflect widely accepted best practices… but that competent engineers would have already configured their TLS 1.2 deployments that way. WolfSSL’s Chris Conlon suggested that it made sense for new architectures to include TLS 1.3 for futureproofing, but that he didn’t see an impetus to tear out existing TLS 1.2 configurations as long as they had been maintained properly.

David Hook chimed in again, noting that as an industry, we are making significant mistakes with TLS 1.3 in the form of design, configuration, implementation, and deployment. The gotcha is that we don’t know which decisions are the mistakes at this point. Maybe in another 12 months, he thought, we might have a better idea of what’s working and what’s not.

In support of this wait-and-see approach, Matt Caswell commented that the OpenSSL project added TLS 1.3 too soon. He said that they could have waited… and probably should have. Brent Cook echoed this sentiment, adding that the LibreSSL team recognized significant costs associated with being early adopters. Specifically, they were making additions to the code as quickly as possible, only to spend more time reverting back to previous versions and making changes to those newest additions. They began enforcing a 2 week delay on TLS updates, just to be sure that patches were going to stick. Even Conlon offered more insight into the growing pains, saying that half of the people trying TLS 1.3 with WolfSSL were running into major issues. Even more telling, the only people experimenting with TLS 1.3 were outliers, not mainstream production.

Possibly the most disturbing part of the session was Caswell’s summary explanation of “middle boxes” and how a technical problem with the handshake was solved with old technology and an alteration to the TLS 1.3 standard. (Give that a Google if you dare.)

I came away from the panel believing that TLS 1.3 has become something of a mirage based on FUD and FOMO. Everyone on the industry side is convinced that they are the only ones that aren’t deploying it, so they are stressing out and sounding the alarms. Meanwhile, relatively few are actually tackling it, and they are stressing out because it is a struggle. Those gains in performance and the all-important future-proofing? They can wait a few more months for the terrain to even out. Don’t worry, we’ll get there as an industry. It just doesn’t have to be today.

Even more complicated, if you’re here and reading this blog, you have concerns about TLS 1.3 in conjunction with FIPS 140-2 validation. OpenSSL continues to be the most common architecture, and rest assured that until they release their version 3.0, which has been promised to support both TLS 1.3 and FIPS mode, TLS 1.3 cannot become table stakes. OpenSSL’s 1.1.x version supports TLS 1.3, thanks to Matt Caswell and his teammates’ efforts and tolerance of frustration, while their legacy 1.0.2x version supports FIPS. There is no option that does both yet. Some vendors have taken on the overhead of building two SKUs, deploying each version respectively, so that they can offer TLS 1.3 and FIPS 140-2…. but the fine print will reveal that buyers must choose between them. 

Our recommendation? Sit tight.

Fear of missing out is a powerful motivator, but there are logical reasons to bide your time. When OpenSSL releases version 3.0, it will kickstart the ubiquity of TLS 1.3, and SafeLogic will release our architecturally compatible version of CryptoComply at the same time. Save your engineering cycles for this major step forward. Your marketing team might hassle you a little bit for not competing on TLS 1.3 just yet, but you can give them a strong technical narrative to counteract your rivals, since you just read this blog. Sometimes the best action is no action, and this is one of those times. 

Don’t get lured into investing hundreds of hours to shoe-horn TLS 1.3 into a custom solution that will quickly become obsolete, or investing in a proprietary stack that condemns you to vendor lock-in. When the leading developers in the open source cryptographic community voice regret that they had acted too soon, it’s smart to listen. Be patient, stay the course, and be diligent in your TLS 1.2 configuration in the meantime.