The messy, musical process behind the web’s new security standard

The web is a big place, and changing the way it works isn’t a simple process. But it has to happen somehow or we’d all still be using Mosaic and transmitting our private data in cleartext. A new security standard called TLS 1.3 is the latest big change to how our browsers communicate, but the process by which it was created is a little weirder and less structured than you might think.

“Anyone can participate from anywhere. There’s no cost — you can just send your stuff in,” said Sean Turner of the Internet Engineering Task Force, an official sort of collective that evaluates new standards for the web and decrees them best practices.

Turner and Joe Salowey, with whom I spoke after the standard was approved, are co-chairs of the Working Group that put together TLS 1.3 that upends years of security practices — all for the better, they hope.

Far from being a smoke-filled room where elites and captains of industry dictate the protocols and algorithms that will define the next generation of online products and services, the IETF and bodies like it are throwbacks to the early days of the internet: lots of giant open email threads, hard tech talk and almost certainly a lot of subtle shade thrown at each other’s Linux distributions.

But it’s still something of a closed system: How does the average developer get their suggestions considered by the committee considering a given proposal or piece of code? In the past pretty much everything was done by mailing lists. It worked well enough, but for TLS 1.3 the team decided to shake things up and move the process into a semblance of modernity.

“This time we did things a little different,” Sean said. “We actually put the document on GitHub and let anyone comment. And then we were getting these comments where we were like, who are these people and how are they so good at this?”

“The IETF has generally had this process with the mailing list,” explained co-chair Joe Salowey. “GitHub provided a richer mechanism for communication. It let people actually propose changes to the document that anyone could see.”

“You had to actually propose what you wanted to see in the text rather than say, ‘I want to make this faster by changing it to this.’ It can be difficult to express those details on the mailing list, he continued. “GitHub facilitated that exchange, the direct editing.”

Despite said facilitation, the process of creating TLS 1.3 took four years, which for people in the security world is simultaneously forever and no time at all. Standards must be ruthlessly vetted and optimized, since once in place they’ll be used billions of times a day and a mistake or rushed protocol could derail entire businesses. But at the same time, the security world is one of constant and evolving danger — so the sooner a better option is adopted, the better.

“Every week there was another attack and people were like, ‘please make this stop,’ ” said Turner. But the process was neither shorter nor longer than it had to be. “People will say, oh it took so long. It took four years, and the average time is actually probably four years. We actually built in pauses so researchers could check stuff.”

“We had participation from lots of people: browser makers, privacy advocates, Mozilla, the ACLU. We also got the researcher community involved and it was a wild success, to be perfectly honest,” said Salowey. “People were following different aspects of TLS and were able to provide feedback throughout the process.”

Ultimately however, the group had to fall back on its legacy options: in-person discussion and the mailing list, which are the final arbiters for negotiation and ratification respectively.

“There were a couple times we were stuck, but eventually it was about whether or not it works. If it was over two or three bytes, people would get over that.” Turner recalled of an IETF meeting in Hawaii. “One time we were at a meeting and two people agreed on the way forward — I pointed out that one of them worked for the ACLU and one worked for the NSA. I figure that’s the possible consensus.”

But it doesn’t just come down to majority rule.

“We don’t vote, we use things like hum,” Turner said. At first I thought “hum” must be an acronym or some specialized mail daemon. But when I asked about the practice, it turned out to be weirder and in a way more elegant than anything I could think up.

“We literally ask people in the room to hum,” he clarified. “It’s very Quaker-ish and they’ve been doing it for a long time. It just kinda works.”

“It gives a chance to be more anonymous rather than raising a hand or vote,” said Salowey.

“People stand up and spread out, and we make sure the bosses are there. People can not hum, they can hum at whatever vol they want,” explained Turner. “People will hum yes and then one person will hum no, and he’ll convince everyone that they were wrong.”

Anyone can volunteer to be more specific than humming or ask for more information, but there you have it: the future of the web is at least partly decided by people in a room humming together.

Technically there’s a final consensus process done by email, but clearly the hum has stuck around for a reason.

In this case the team was more than happy at what they’d managed to create.

“It’s really hard to deploy crypto, but trying to get rid of stuff that’s out there is even harder,” said Turner. “We got away with simplifying, getting rid of the cruft.”

“We took a lot of things out. We did surgery on pieces of the protocol that were prone to attracting vulnerabilities,” added Salowey. “That’s a hard thing to do. Some of the things that people may still rely on in certain circumstances are going to be going away, because the mechanisms are not as secure or robust as modern ones.”

“But there were tangible benefits, speed and security — people were like, ‘let’s get together on this,’ ” he continued.

So everyone’s a little safer, but both Salowey and Turner downplayed any credit they and their colleagues might be due for guiding the process.

“People aren’t in it for individual fame or glory…we don’t really work that way,” said Turner. “If you can make something better or faster that’s just good.”

Was there any tangible benefit aside from the warm, fuzzy feeling developers get after reducing the turnaround time for an encrypted packet?

“Well… I made t-shirts for everyone,” Turner said.

“And stickers!” said Salowey.

You can get humming with the IETF by learning more here.