The IETF had its 100th meeting the week of November 13. It was held in Singapore. I want to report on two pieces of good news.
The first is that it seems like TLS 1.3 is ready to advance through the IETF process. As I wrote last month, the problem was that outdated or buggy network devices between the endpoints — or, in fact, any entity between the endpoints — could break the connection and force a downgrade to TLS 1.2.
During the TLS working group session, David Benjamin of Google presented the results of some experiments to work around this issue. They can be found on pages 7-11 of the protocol update slides. In short, by tweaking some of the version identifiers, and adding some old-style messages which both halves ignore, they are able to “fool” the middleboxes into accepting the TLS traffic because they erroneously recognize it as TLS 1.2. By doing this, they were able to bring the successful connection rate up from 95.8% to 98%, on par with TLS 1.2.
The changes are inelegant — they offend “geek esthetics” about network protocols. Fortunately, they do not affect any of the security properties, and therefore security analysis, of the protocol. As an amusing proof-point that they work as designed, the popular free tool Wireshark just got updates to support the TLS 1.3 changes. As tweeted by the author, without the update Wireshark reported the protocol as TLS 1.2.
Everyone is moving rapidly to deploy the changes into their code. There is already an OpenSSL pull request, and like Chrome, Firefox has a version available in their cutting-edge releases. With any luck, the IETF will move rapidly on this as well and we’ll all be able to deploy the official TLS 1.3 early next year. The version with the middlebox changes, draft 22, was published at the end of November.
The second piece of good news is about telephone spam. In particular, those scams from “Card Services” promising to lower your credit card balances, or “The IRS” threatening you with jail time for nonpayment of (non-existent) back taxes.
Akamai was a founding sponsor of Let’s Encrypt, the Certification Authority that issues TLS server certificates for free. An important aspect of the project was the design and use of an application protocol to automate certificate issuance. Following the IETF tradition of coining short names for things, the protocol is called ACME and it is also in working group last call. I have been a co-chair of the working group since it’s inception.
Another working group for secure telephone identity known as STIR (see what I mean by the short names?) has developed a framework to use ACME to generate certificates for smartphones and SIP/network phones (known as “soft phones”). Certificates could be issued by Telco’s, SIM card providers, and large enterprises with IP phones. That last deployment will help prevent corporate “phishing” attempts, when someone claiming to be the CEO intimidates the helpdesk into providing, or resetting, their password. The elegance and generality of ACME, coupled with the ubiquity of the Internet’s protocols, could help bring down these hassles and threats to near-zero levels. It’s not something we envisioned when we helped start Let’s Encrypt a few years ago, but it is something we are proud to still be a part of. If we never have to take a call from “Jenny from card services” ever again, it will be more than worth it.
These are two examples of our standards involvement, and how it helps us do a better job at enabling our customers to provide the best possible experience. Sometimes the results are expected and sometimes there is an unexpected bonus result. We’re excited for more of the same in 2018!
This is a Security Bloggers Network syndicated blog post authored by Rich Salz. Read the original post at: The Akamai Blog