Skip to main content
  • IETF LLC Board Retreat 2026

    The IETF Administration LLC Board of Directors held its annual retreat 29-30 April 2026 in Amsterdam. In addition to all Board members, the IETF Executive Director, the Director of Finance, and the Board Secretary were present. Here is a short summary of the main points we discussed.

    4 Jun 2026
  • IETF Administration LLC 2025 Annual Financial Audit

    IETF Administration LLC Board of Directors received from external auditors the report of a clean result for its 2025 annual financial statement.

    26 May 2026
  • New RFC Editor website is live

    Today we are launching the new rfc-editor.org website, the most visible part of a comprehensive overhaul of the tools that support editing and publishing RFCs.

    20 May 2026
  • IETF 125 Highlights

    More than 1500 participants gathered in Shenzhen and online for the IETF 125 meeting 14-20 March 2026 for more than 100 working sessions, an IETF Hackathon, and more.

    19 May 2026
  • Report from the 2026 RPC Retreat

    The RFC Production Center (RPC) retreat was a two-day strategic planning session taking place the week of April 20 that gathered the entire RPC team and IETF Administration senior staff.

    18 May 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