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

Toerless Eckert <> Tue, 13 October 2020 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2928C3A0407 for <>; Tue, 13 Oct 2020 07:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GAnQyaZHwuWY for <>; Tue, 13 Oct 2020 07:29:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DDA43A0400 for <>; Tue, 13 Oct 2020 07:29:44 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id DCA38548042; Tue, 13 Oct 2020 16:29:38 +0200 (CEST)
Received: by (Postfix, from userid 10463) id D63C4440059; Tue, 13 Oct 2020 16:29:38 +0200 (CEST)
Date: Tue, 13 Oct 2020 16:29:38 +0200
From: Toerless Eckert <>
To: Brian E Carpenter <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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: Tue, 13 Oct 2020 14:29:48 -0000

Some crazy thoughts:

One technical aspect IMHO worth of technical consideration is to think and work
along the motivation of RFC3924. From my understanding, Fred did this to provide more
awareness and transparency of perpass technology used (i hope he will correct me
if this is wrong).

Aka: Government actions such as filtering and perpass will increase, for better
or worse. They may only happen at application layer or at network layer. What
technical stndards could be build to record, track and supervise these government
actions ? 

For example: could we create standardized methods for more transparency of
these government actions and policies ? Of course, there are a lot of policy
and dministrative aspects to any such means for transparency, e.g.: who is given
the ability to review and control the actions of the legal enforcers. Could the
metadata about filtering and perpass for example be anonymized such that control
and review of such legal enforcers could more easily be done by more independent
entities. Could there be a data-model about the metadata that an SP could
directly expose to such independent watchdogs ? Think from the minimum
to the maximum: Total number of new filter/perpass requests in a period
as an example of a minimum. Any degree of visibility IMHO would help. Time
delayed availability to not impact immediate executive action etc. pp!

Aka: This is not talking about defining how to do filter/perpass, but how
to monitor and control those who do perform those legal actions.

IMHO: There is not only more privacy for individuals, there is also the
need for more transparency of legal activities. IMHO, the core reason why we have
the quagmire about democratic government actions is their secrecy,
unaccountability and therefore uncontrollability.

Practically speaking, SPs could simply create databases of all executives
LI requests/actions, and then regularily but accidentially the database is
leaked like all our credit card numbers regularily are. 


On Mon, Oct 12, 2020 at 08:27:05AM +1300, Brian E Carpenter wrote:
> Not to mention RFC 7258.
> Orders from the Top: The EU???s Timetable for Dismantling End-to-End Encryption:
> Five Eyes and Japan call for Facebook backdoor to monitor crime
> Regards
>    Brian Carpenter
> _______________________________________________
> Architecture-discuss mailing list