Skip to main content
  • A New Model for the RFC Editor Function

    The new RFC Editor Model is intended to provide greater transparency, improved responsiveness to the needs of the community, and increased clarity regarding the roles and responsibilities of the groups and individuals involved.

    • Peter Saint-Andre
    27 Jun 2022
  • Finalizing the IETF tools transition

    The final stage of transitioning services from tools.ietf.org will take place over the next few weeks. New services are in place, and some older services will disappear. Several measures are planned to ensure these final steps proceed smoothly.

    • Robert SparksIETF Tools Project Manager
    17 Jun 2022
  • Update from the first in-person IAB, IESG, and IETF LLC Board joint retreat

    The IAB, IESG, and IETF LLC Board convened for the first joint retreat in San Francisco from May 17 to 20, 2022, generously hosted by Google at one of their offices.

    • Mirja KühlewindIAB Chair
    15 Jun 2022
  • Towards a net zero IETF

    Introducing a new project to measure and potentially offset IETF carbon emissions so that the IETF could potentially reach the level of a net zero emitter.

    • Jay DaleyIETF Executive Director
    6 May 2022
  • IETF 113 post-meeting survey

    The results from our IETF 113 post-meeting survey are now available on a web-based interactive dashboard. This commentary highlights where changes we have made based on feedback have been a success, and areas we still need to work on.

    • Jay DaleyIETF Executive Director
    2 May 2022

Filter by topic and date

Filter by topic and date

Improving Security in the Internet: The Diffie-Hellman Case Study

  • Paul Wouters
  • Jari Arkko

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.

Great Paris Cipher

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)


Share this page