Filter by topic and date
Improving Security in the Internet: The Diffie-Hellman Case Study
22 Oct 2015
A recent paper on shortcomings of Diffie-Hellman key exchange has received attention and raised questions about security on the Internet, as Diffie-Hellman is used for cryptographic handshakes in popular Internet protocols.
While the specific issues from the paper are new, the underlying issues have been known for a while by those working on security-related protocols in the IETF. In fact, work across the IETF in this area is underway, motivated in part by an IETF-wide discussion begun nearly two years ago which identified pervasive surveillance as an attack on the Internet that should be mitigated in the design of Internet protocols (RFC 7258).
For example, the IETF Using TLS in Applications (UTA) Working Group summarized security attacks in RFC 7457, including those related to the ones raised in the paper. The goal of RFC 7457 is to motivate improvements to some of the protocols used to secure Internet transmissions, such as Web pages that have URLs that start with “HTTPS://”. Following RFC 7457, the UTA Working Group has produced RFC 7525, which provides recommendations on improving the security of deployed services that use TLS by using specific, stronger cipher suites.
Similar work is happening with IKE/IPsec, which is a protocol suite for secure Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. The IETF IPsecME Working Group regularly updates its cryptographic algorithm advice for implementors. The original IKE specification in RFC 2409 and updated in RFC 3526 together specify the two most commonly used Diffie-Hellman key sizes of 1024 (DH 1024) and 1536 bits. This was updated in IKE version 2 in RFC 4307 in 2005 where it recommended Diffie-Hellman key sizes of 2048 bits and demoted DH 1024. However, the industry has been slow adopting these updated recommendations and as a result of the recent revelations, work has started on updating RFC 4307 which will completely remove support for DH 1024.
There are also some subtleties relating to IPsec that make it different from TLS. For example, unlike TLS servers, IPsec can initially appear to accept weaker cryptographic options only to reject those later in the session establishment phase. As such, it is actually nearly impossible for an Internet probe to determine the strength of the cryptographic parameters required by an IPsec server. For more information, see this article by Paul Wouters.
So, as we approach the second anniversary of the discussion that led to RFC 7258, the IETF community has done considerable work to strengthen trust in the Internet, in line with its mission of “making Internet work better”. But, a lot of work also remains – in deploying the better versions, in building defences to new attacks, and in understanding the issues and possible improvements. This is a continuous process.
(Picture credits: The Great Paris Cipher from UK National Archives)