Hurrah! TLS 1.3 is here. Now to implement it and put it into software

The ink has dried, so to speak, on TLS 1.3, so it's time for work developing software to implement the standard to begin in earnest.

As we reported last week, now that the protocol's received the necessary consensus in the IETF, implementation “will require people to put in some effort to make it all work properly.”

Vulture South talked to one of the people involved in that implementation, Mauritian developer Loganaden Velvindron, who said the biggest change he's seen since the Singapore IETF 100 last October is that developers no longer seem so wary of the protocol.

“What was interesting to me is that finally, open source developers are no longer saying 'wait and see' about TLS 1.3,” said Velvindron, who participated in the TLS 1.3 hackathon for IETF 101 in London^*.

Velvindron said the hackathon's work to build TLS 1.3 into OpenSSL was the gathering's most important contribution, since that will have the most upstream impacts.

The OpenSSL architecture helped: it “abstracts a lot of the low-level changes [behind] the API,” he said.

His team had a bunch of other projects ready to go by the end of the hackathon: the ubiquitous wget command-line HTTP retrieval library, the Nagios-plugins set of network system monitoring packages, the Git and Mercurial version control libraries, the Eclipse Paho machine-to-machine library, and the Monit process/file monitor.

Along the way, Velvindron said, the team discovered a misconstruction in how servers construct the CLIENT HELLO that other app maintainers should watch out for.

He said some applications “don't work with 1.3 because ... the CLIENT HELLO is not constructed correctly, it causes handshake failures”, he said.

Also, Velvindron told us, while the signed-off TLS 1.3 included a resolution to the “middlebox controversy”, it could take a while for that to be implemented in the field.

Middleboxes – chiefly enterprise-edge traffic inspectors and packet filters – were one of the points of contention that helped delay TLS 1.3 for four years.

The IETF decided that systems like OpenSSL should ship with “middlebox compatibility” enabled by default. In this mode, the TLS 1.3 connection looks like TLS 1.2, Velvindron said.

“Assuming that the middlebox implements TLS 1.2 correctly, then the session goes through … it looks like TLS 1.2, but it's using TLS 1.3.”

That means, for example, that some of the worst aspects of TLS 1.2 – for example, that hackers could trick the system into reverting to an old and insecure ciphersuite – are plugged without customers having to undertake a large-scale upgrade to existing systems.

If there's anything wrong with how the middlebox implements TLS 1.2, the connection will break and users will get a warning, and Velvindron said some middleboxes will probably need a firmware upgrade.

What's next: DNS privacy

TLS 1.3 implementation is a long way from finished, but with the project well begun, the group behind it is branching out.

One project that's caught their eye is the IETF's work on DNS privacy, making sure that encrypted DNS sessions don't leak information.

“You still need RFC 7830, DNS padding”, Velvindron told Vulture South.

That's because even the size of an encrypted message can “leak information about the message,” he explained, “and that can make it easier for snoopers to get an idea of the kind of message going through.”

Padding under RFC 7830 makes sure the packet aligns to a particular block size.

One thing that emerged during IETF 101 is that DNS is becoming unwieldy: according to Velvindron, noted Power DNS developer Bert Hubert asked in a presentation: “How many features can we add to this protocol before it breaks?”

Since there are 185 DNS-related RFCs, things could already be starting to creak, which is why Hubert has created the “DNS Camel” (code at GitHub), which is crawling IETF archives for DNS-related documents (the tabulation is here).

“Very few people understand all those features, they're a very small group in the IETF”, Velvindron told Vulture South.

A result is a growing concern that developers tend to work in isolation: “We don't test a feature with other DNS features to make sure it interpolates correctly.”

There was a consensus, he said, that this needs to change – that developers need to test their DNS features against others.

As part of that, the meeting discussed the need to bring ISPs on board, to explain which features they're using, so developers know what's important to test against. ®

^*Other hackathon participants and hackers.mu members were Pirabarlen Cheenaramen, Nitin Mutkawoa, Codarren Velvindron, Yasir Auleear, Rahul Golam, Nigel Yong Sao Yong and Yash Paupiah.