Last week I participated in the third International Cryptographic Module Conference (ICMC), organized by the Cryptographic Module User Forum (CMUF), and concerned with the validation of cryptographic modules against government and international standards. You may think of cryptographic module validation as a dry topic, but it was quite an exciting conference, full of technical and political controversy. The technical controversy resulted from the fact that the standards are out of sync with current technology and it is not at all clear how they can be fixed. The political controversy resulted from the fact that, after Snowden’s revelations, it is not at all clear who should try to fix them. The organizers signalled that they were not afraid of controversy by inviting as keynote speakers both Phil Zimmerman, creator of PGP and co-founder of Silent Circle, and Marianne Bailey, Deputy CIO for Cybersecurity at the US Department of Defense, besides well known expert Paul Kocher of SSL fame. I enjoyed an exchange between Zimmerman and Bailey on the imbalance between defense and offense at the NSA and its impact on cybersecurity. Continue reading “Cryptographic Module Standards at a Crossroads after Snowden’s Revelations”
One difficulty faced by privacy-enhancing credentials (such as U-Prove tokens, Idemix anonymous credentials, or credentials based on group signatures), is the fact that they are not supported by TLS. We noticed this when we looked at privacy-enhancing credentials in the context of NSTIC, and we proposed an architecture for the NSTIC ecosystem that included an extension of TLS to accommodate them.
Several other things are wrong with TLS. Performance is poor over satellite links due to the additional roundtrips and the transmission of certificate chains during the handshake. Client and attribute certificates, when used, are sent in the clear. And there has been a long list of TLS vulnerabilities, some of which have not been addressed, while others are addressed in TLS versions and extensions that are not broadly deployed.
The November SSL Pulse reported that only 18.2% of surveyed web sites supported TLS 1.1, which dates back to April 2006, only 20.7% supported TLS 1.2, which dates back to August 2008, and only 30.6% had server-side protection against the BEAST attack, which requires either TLS 1.1 or TLS 1.2. This indicates upgrade fatigue, which may be due to the age of the protocol and the large number of versions and extensions that it has accumulated during its long life. Changing the configuration of a TLS implementation to protect against vulnerabilities without shutting out a large portion of the user base is a complex task that IT personnel is no doubt loath to tackle.
So perhaps it is time to restart from scratch, designing a new transport layer security protocol — actually, two of them, one for connections and the other for datagrams — that will incorporate the lessons learned from TLS — and DTLS — while discarding the heavy baggage of old code and backward compatibility requirements.
We have written a new white paper that recapitulates the drawbacks of TLS and discusses ingredients for a possible replacement.
The paper emphasizes the benefits of redesigning transport layer security for the military, because the military in particular should be very much interested in better transport layer security protocols. The military should be interested in better performance over satellite and radio links, for obvious reasons. It should be interested in increased security, because so much is at stake in the security of military networks. And I would argue that it should also be interested in increased privacy, because what is viewed as privacy on the Internet may be viewed as resistance to traffic analysis in military networks.
We have written a response to the Call for Comments on the report entitled Cybersecurity, Innovations and the Internet Economy, written by the Internet Policy Task Force of the US Department of Commerce.
In the response we call for research and development efforts aimed at improving and broadening the scope of the TLS protocol (formerly known as SSL). This would benefit NSTIC and the many IETF protocols that rely on TLS for their security.
If you have any comments on our response, please leave then below.