Re: [arch-d] Time to reboot RFC1984 and RFC2804?
Toerless Eckert <tte@cs.fau.de> Tue, 13 October 2020 14:29 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2928C3A0407 for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 07:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAnQyaZHwuWY for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 07:29:45 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDA43A0400 for <architecture-discuss@ietf.org>; Tue, 13 Oct 2020 07:29:44 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DCA38548042; Tue, 13 Oct 2020 16:29:38 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (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 <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: architecture-discuss@ietf.org
Message-ID: <20201013142938.GB55488@faui48f.informatik.uni-erlangen.de>
References: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/PBMHyAr3_ISqeE3mEkpFou98EKY>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=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. Cheers Toerless 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: > https://www.eff.org/deeplinks/2020/10/orders-top-eus-timetable-dismantling-end-end-encryption > > Five Eyes and Japan call for Facebook backdoor to monitor crime > https://asia.nikkei.com/Business/Technology/Five-Eyes-and-Japan-call-for-Facebook-backdoor-to-monitor-crime > > Regards > Brian Carpenter > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de
- [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Mo Balaa
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Vittorio Bertola
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Joel M. Halpern
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? John C Klensin
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Christian Huitema
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stewart Bryant
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Stephen Farrell
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Toerless Eckert
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Andrew Campling
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Eliot Lear
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Guntur Wiseno Putra
- Re: [arch-d] Time to reboot RFC1984 and RFC2804? Brian E Carpenter