Unless you’ve been living under a rock this century, you are probably aware of the rapidly increasing cyber threat of nation-states and organized crime. Earlier this week, the Internet Engineering Task Force (IETF), the premier Internet standards development body, tied one hand behind the back of companies looking to secure their customers’ data by paternalistically advancing a standard that effectively prohibits companies from examining their operations for evidence of malicious activity.
Andrew Kennedy is a Director of BITS, FSR’s technology policy division.
This is akin to some third-party prohibiting bank security guards from patrolling and checking particular rooms in the bank.
For nearly two years, enterprises have been working within the IETF to ensure critical risk and operational management capabilities remain available in future versions of Transport Layer Security (TLS), the ubiquitous encryption protocol that underpins confidentiality within data centers and across the Internet. Without the IETF’s endorsement, any revision to TLS would most likely be prevented, thereby molding security deployments. The capability to inspect encrypted custodial data has been available for nearly a quarter of a century and serves to protect customers and enterprises against data breach from phishing attacks, advanced persistent threats, and insider threat, and to expedite the diagnosis and resolution of critical network anomalies.
That effort derailed in London at the 101st IETF meeting when the TLS Working Group, in a theatrical call for consensus, deadlocked on whether to review the most recent industry proposal. This proposal, the second of its kind, was engineered at the request of privacy purists as an optional TLS extension, requiring client opt-in and transparency for end-users.
Despite meeting these requests, the goalposts moved: many of those making the request then voice voted down the procedural step of conducting a comprehensive review of the extension by the TLS Working Group.
With the IETF door all but closed, enterprises are left with few good choices if they are to safely allow TLS 1.3 inside their networks.
One option would be for enterprises to revisit alternative solutions that work within the forthcoming TLS 1.3 standard. While some of the solutions would be attractive to enterprises because of their engineering simplicity, this is likely the privacy community’s least preferred outcome since these implementations tend to lack transparency for clients. Yet by allowing questionable privacy concerns to upend the search for a mutually beneficial solution at the IETF, this option ironically becomes the path of least resistance.
Another way forward is to submit our proposals to other standards bodies. This option is currently seen as less likely to achieve a desirable outcome because without the IETF stamp of approval, it isn’t clear the vendor community would update products and tools with the necessary support.
Additional paths forward may also reveal themselves shortly. One entrepreneurial IETFer took the microphone to announce he had patented a solution in this space as an alternative to the standards-based process, eliciting both groans and laughter from the otherwise tense audience.
Despite these murky paths forward, what is clear is that demand for a TLS 1.3 enterprise solution will not go away. At the TLS Working Group session, it was mentioned that a nation-state attacked US critical infrastructure and that the Indictors of Compromise (IoC) of this incident would not have been readily apparent under TLS 1.3. This is the latest, but it won’t be the last, demonstration that defending against all threat models is essential to sound cybersecurity practices.
As to whether a middle ground solution can ever be established remains to be seen. But what is clear is that forward-thinking enterprises will not sit on the sidelines and allow paradoxical privacy concerns to be weaponized to the benefit of hostile nation-states and organized crime and to impact firms and the customers they work hard to protect.
