Skip to main content
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026
  • Secretariat restructuring and staffing update

    There have been a few changes in IETF Administration LLC staffing since January of this year (2026) including the recent insourcing of the Secretariat, which are summarised here to give an overall view of the staffing structure.

    30 Jul 2026

Filter by topic and date

Filter by topic and date

1984

25 Sep 2015

One of the things that can make surveillance too easy is when the technology we use has weaknesses.

strong lock

Not what you think! This blog post is not about the novel by George Orwell. Although the topic is related, as all-encompassing surveillance is a big question both in the novel and in today’s Internet communications. One of the things that can make surveillance too easy is when the technology we use has weaknesses.

The IETF recently approved RFC 1984 to the status of “Best Current Pratice”, or a document that has the strength of a recommendation for the broader Internet community. This document discusses the need for strong, cryptographic protection of communications, and makes a case that limiting access to these tools will weaken everybody’s security in the Internet. The RFC was relevant in 1996 when it was first published and still is today; the principles described in RFC 1984 have held up well in the nearly two decades. 

For both symbolic reasons and to better ensure that IETF specifications reflect the spirit of RFC 1984, the IETF participants wanted to recognize the substantive content of RFC 1984 as a BCP.

The Security Area of the IETF had rough consensus to change the status of RFC 1984 to BCP in-place. The possibility of revising the text of RFC 1984 was discussed, but rejected because a) the current text is still fine, b) any changes we’d likely make now wouldn’t improve it significantly, c) affirming the continuity of the IETF’s position is valuable and even d) keeping the RFC number is worthwhile. Thus, though this update is exceptional, this in-place status change is overall considered reasonable and beneficial.

Picture credits Wikimedia and Jari Arkko


Share this page