Skip to main content
  • QUIC working group looks to bring more security to Internet traffic

    Lucas Pardue serves as co-chair of the IETF QUIC Working Group, which focuses on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. The IETF blog recently asked Pardue about the QUIC standards project.

    • Grant GrossIETF Blog Reporter
    14 Jun 2021
  • Q&A with our new Director of Development

    Lee-Berkeley Shaw joins the IETF Administration LLC today as Director of Development. She will focus on designing and delivering the strategy to achieve the IETF’s goals for financial sustainability, with a focus on growing the IETF Endowment. We asked her questions about her plans for the IETF and her background.

    • Grant GrossIETF Blog Reporter
    7 Jun 2021
  • A new era in Internet transport

    The IETF’s Transport and Services (TSV) area is developing several potentially transformative technologies while it continues to maintain many of the foundational protocols of the Internet.

    • Martin DukeTransport Area Director
    • Zaheduzzaman SarkerTransport Area Director
    • Magnus Westerlund
    3 Jun 2021
  • Innovative New Technology for Sending Data Over the Internet Published as Open Standard

    Already broadly deployed and used, QUIC provides lower delay, improved security, and more robust delivery of data.

      3 Jun 2021
    • QUIC in the Internet industry

      QUIC, a new Internet transport technology that improves web application performance, security and privacy, was reviewed, redesigned and improved in the IETF, incorporating a broad range of input from across the industry.

        3 Jun 2021

      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