“Measure twice, cut once,” is a good way to approach new protocols, and TLS 1.3 is no exception.
When it comes to approving updates to key security protocols, the Internet Engineering Task Force may seem to move slowly as it measures the impact of changes to important protocols. In the case of the long-awaited update to version 1.3 of the Transport Layer Security protocol, the IETF’s TLS work group has been moving especially slowly — but for good reasons.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The TLS protocol provides privacy (encryption) and authentication for internet applications operating over the Transmission Control Protocol (TCP); TLS is a critically important protocol for enforcing security over the web. The current proposed standard, TLS 1.2, was published in 2008 and is the latest in a line of protocols dating back to the first transport layer security protocol used to secure the web, the Secure Sockets Layer (SSL), which was first published by Netscape in 1995.
The first draft version of the latest update was published for discussion by the TLS work group in April 2014, and SearchSecurity has been covering the imminent release of TLS 1.3 since 2015. Despite the long wait for a TLS 1.3 release date, I’m happy to continue waiting given all that we’ve learned from the process so far.
There is no questioning that TLS is in need of updating. The new version of the protocol will add several important features, including most prominently the preference for support of perfect forward secrecy. Perhaps more important is the thorough pruning of obsolete or otherwise “legacy” algorithms. As the authors of the latest TLS 1.3 draft (version 22!) put it, “[s]tatic RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.” Other updates include some performance boosts as well as improvements in the security of key generation and the handshake protocol.
As Akamai Technologies’ Rich Salz put it in an October 2017 blog post, the new version of TLS is faster, more reliable and more secure; all things to be desired in a security protocol.
All in all, these are positive moves, but why is it taking so long to officially update the TLS 1.3 specification and publish it as an RFC?
It’s taking so long because the system is working.
The process is intended to flush out protocol issues, especially as they relate to protocol implementations. Just because TLS 1.3 is not yet officially released, vendors — like Cloudflare, Akamai, Google and many others — have been rolling out support for TLS 1.3, and reporting on the issues as they uncover them. And issues have been uncovered:
David Benjamin, a Google developer who works on the Chromium project, wrote in a post to a TLS working group list that “TLS 1.3 appears to have tripped over” a dodgy version of RSA’s BSAFE library that some have theorized was put in place by RSA at the request of the National Security Agency (NSA).
Matthew Green, cryptography expert and professor at Johns Hopkins University, spelled out why the discovery of that BSAFE flaw may shed light on how that “theorized NSA backdoor” worked.
That is a positive outcome, especially as it gives security professionals an excellent reason to root out the potentially exploitable code.
Boxes in the middle
Another important issue that the process uncovered was that of misbehaving middleboxes, which earlier in 2017 were cited as the primary reason that TLS 1.3 appeared to be breaking the internet.
Middleboxes are the systems, usually security appliances, that sit “in the middle” between servers and clients and provide security through packet inspection. To actually inspect packets that have been encrypted using TLS, the middleboxes need to act as proxies for the clients, setting up one secure TLS connection between the client and the middlebox and another between the middlebox and the server.
It turns out that TLS 1.3 causes some issues with middleboxes, not because of anything wrong with the new protocol, but because of problems with the way middlebox vendors implemented TLS support into their products, causing them to fail when attempting to negotiate TLS connections with endpoints using the TLS 1.3. The solution will likely involve some tweaking of the updated protocol to compensate for unruly implementations while pressuring vendors to fix their implementations.
These issues with the TLS 1.3 draft likely contributed to the lengthy delay in the specification being finalized. I expect TLS 1.3 to be published sometime next year, although that’s what I’ve expected for the last three years.
But given what we’ve already learned from the process, that’s just fine.