Re: [arch-d] Time to reboot RFC1984 and RFC2804?

John C Klensin <> Sun, 11 October 2020 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117243A07AE for <>; Sun, 11 Oct 2020 14:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0cAF50oUFRCy for <>; Sun, 11 Oct 2020 14:20:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 489793A07A0 for <>; Sun, 11 Oct 2020 14:20:18 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1kRilH-0002hd-61; Sun, 11 Oct 2020 17:20:11 -0400
Date: Sun, 11 Oct 2020 17:20:04 -0400
From: John C Klensin <>
To: Brian E Carpenter <>
Message-ID: <975E28FE326C22E8CD32DCC8@PSB>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Oct 2020 21:20:20 -0000

--On Monday, October 12, 2020 08:27 +1300 Brian E Carpenter
<> wrote:

> Not to mention RFC 7258.
> Orders from the Top: The EU's Timetable for Dismantling
> End-to-End Encryption:
> -dismantling-end-end-encryption
> Five Eyes and Japan call for Facebook backdoor to monitor crime
> n-call-for-Facebook-backdoor-to-monitor-crime  


This, plus another variation on the theme [1], is what has been
concerning me for some time.  It has caused an occasional rant
but I'm mostly stayed silent because the IETF consensus (at
least when 7258 was published) seemed clear.

It seems to me that we (very broadly defined) may be headed into
a period in which:

(1) We are forced into a choice between encryption and other
technical privacy protections against attacks (borrowing the
7258 language) by individuals and attacks by governments
(including law enforcement), especially governments who have
jurisdiction over the sender, receiver, or other.  The default
if we don't choose and make the distinction clear to others may
be "neither".


(2) We are forced into a choice between an open and global
Internet and one that is very fragmented with security and
privacy protective only within mutually-isolated more local
networks.  We would have either no communication among those
local networks or content filtering, application-level, gateways
at politically selected boundaries.  Refusing to chose might
result in both bad outcomes.

I want to stress that I do not advocate or welcome being forced
into those choices or any of the outcomes they might imply.  But
I think it may be where we are headed, with the two pieces you
cite above, increased pressure for "law enforcement access" in a
variety of places, etc., possibly just being road signs on that


[1] The other concern that goes with this involves assorted
enterprises deciding they need to protect themselves from
assorted bad stuff by examination of content crossing their
boundaries. For a subset of them (and their firewall, etc.)
providers, the shift to "encryption everywhere" creates a
challenge that they see no way to deal with other by eliminating
client desktop to server (or other end to end) encryption and
replacing it with client to middlebox/ middlebox to server
mechanisms, preserving encryption across the public Internet at
the cost of a single point of failure with access to cleartext
at their boundary middleboxes.