No going back on forward secrecy
The Electronic Frontier Foundation (EFF) has waded into a rumbling row about web encryption standards, arguing that a business group is backing an approach that discards important security controls.
The protocol – first proposed in September 2016 – omits ‘forward secrecy’, a feature baked into Transport Layer Security (TLS) version 1.3. Forward secrecy ensures that intercepted communications resist retrospective decryption, even if an attacker later has a copy of the server’s private key.
Leaving out forward secrecy from ETS “invisibly undermines security and has the potential to seriously worsen data breaches”, the EFF warns.
Previous version of TLS did not make forward secrecy – which comes with a processor overhead – mandatory.
During the long tenure of TLS 1.2, some companies, mostly banks, came to rely on the less taxing standard to get the most performance out of their server farms, according to the EFF.
BITS and pieces
During the TLS 1.3 ratification process, BITS argued its members “depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation”.
Putting forward secrecy in TLS 1.3 would frustrate these monitoring functions, BITS said, adding that TLS 1.3 should offer algorithms that disable forward secrecy in order to facilitate these monitoring functions.
In response to these objections, a proposal was developed called ‘Static Diffie-Hellman’. This involved using the same Diffie-Hellman private key for all connections, rather than randomly generating this value with each new connection.
The Internet Engineering Task Force (IETF), which develops internet standards including TLS, ultimately discarded this approach. BITS, seemingly undaunted, took its concept to ETSI, another standards organization, back in 2017.
The IETF cried foul over this, objecting that the eTLS moniker was confusingly similar to TLS – a battle-hardened protocol developed by the IETF for more than 20 years.
In response, ETSI agreed to call the next revision of their variant Enterprise Transport Security, or ‘ETS’.
Extra Terrible Security
EFF said the approach would be more aptly called “Extra Terrible Security” in criticizing the whole rationale for ETS.
“Internet security as a whole is greatly improved by forward secrecy,” the foundation said. “It’s indefensible to make it worse in the name of protecting a few banks from having to update their legacy decrypt systems.
“Decryption makes networks less secure, and anyone who tells you differently is selling something (probably a decryption middlebox).”
“Don’t use ETS, don’t implement it, and don’t standardize it,” it concluded.
The Daily Swig put these criticisms to ETSI, but we’re yet to receive a response.
BITS is the technology policy division of the Bank Policy Institute, likewise yet to respond. We’ll update this story as and when more information comes to hand.
Independent security experts argued that forward secrecy ought to be mandatory, and that the ETS approach was therefore misguided.
“This is a case of the road to hell being paved with good intentions,” Alan Woodward, computer scientist and a professor at the University of Surrey, told The Daily Swig.
“I can understand that they are trying to make it easier to, for example, monitor inside a data center, but you use a weaker protocol at your peril. Forward secrecy is so valuable removing it will end in tears.”
Infosec expert Scott Helme backed this assessment. “This won’t end well,” Helme said.
Sean Wright, OWASP Scotland chapter leader, said that adding forward secrecy doesn’t preclude monitoring.
“You can still have forward secrecy to a degree and still able to intercept the traffic,” he said. “Do a TLS termination at your device which is monitoring the traffic.”
Professor Woodward agreed: “There are other ways of doing this rather than use a weakened protocol. Even if, for example, the Firewall was doing MiTM there would be no reason to give up forward secrecy.”
Adopting the ETS approach may “propagate risk outside of the arena in which it is intended to be used,” according to Woodward. “My hope is that no one ‘standardizes’ this protocol.”
Infosec specialist Jamie Stallwood added that browser makers should boycott ETS. “Hopefully Chromium and Mozilla will take action to declare it insecure in their browsers,” he said.