Re: [arch-d] Time to reboot RFC1984 and RFC2804?
Toerless Eckert <tte@cs.fau.de> Wed, 14 October 2020 15:31 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 0F0043A0F4F for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 08:31:58 -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 ajSwJGe1Bs5e for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 08:31:55 -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 AC3423A0F4C for <architecture-discuss@ietf.org>; Wed, 14 Oct 2020 08:31:55 -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 0CEF1548441; Wed, 14 Oct 2020 17:31:50 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 00260440059; Wed, 14 Oct 2020 17:31:49 +0200 (CEST)
Date: Wed, 14 Oct 2020 17:31:49 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: architecture-discuss@ietf.org
Message-ID: <20201014153149.GB13376@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/I-TWP1TqwplO7-AnZnISef1wphI>
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: Wed, 14 Oct 2020 15:31:58 -0000
If i may rant about context, and like the rest of the thread it is somewhat recurring: We should remember that a good amount of desire for end-to-end encryption is not only driven by user privacy desire but by the commercial interests of over the top providers wanting to prohibit the underlay operator to interfere with its business model. This is never openly talked about in the IETF, but instead all those OTT that want Internet end-to-end encryption for this reason put all their efforts into promoting the value of privacy over any other conflicting goals: Sounds a lot better than "we don't want SP to get a share in our ad revenue for just transporting our bits" (just as an example). Aka: The IETF has a commercially driven biased view on the relative importance of privacy via end-to-end encryption. And its behaving like a single-issue organization in this respect. As shown through the complete absence of any attempts to tackle / discuss the competing problems that need to be solved such as those of law enforcement. I sent a prior email about additional work that could be done. Same as writing to /dev/null. Let me try a more fundamental competing issue: Firewalls in any commercial organization are there to keep bad stuff from coming in and protected stuff from going out. To that end, in the face of encryption, more and more data-model level inspection devices are emerging allowing organizational security teams to control / inspect if/how cloud based services do comply with those organizational security demands. Nothing of this AFAIK is done in the IETF. Even as a "User", i am a lot more worried these days about all the IoT devices i could have at home and how they perpass and resell my data, than law enforcement agencies putting backdoors into my PC. Where is the IETF on this problem ? It is owned primarily by organizations whose core business model is the (ab)use of User data or those that support such organizations through infrastructure (depending on them) . Considered IOTOPS WG of course has this problem not on the proposed charter either. Any similar IETF statements like RFC7258 about this application level behavior ? AFAIK, no: It is the "evil" (see below) EU that did the first globally relevant scheme to put limits to that abuse: GDPR. Is it as simple and elegant as TLS ? Of course not. Its just like Democracy: worst solution except for all the others. Sorry for the interruption. Please carry on. On Mon, Oct 12, 2020 at 08:27:05AM +1300, Brian E Carpenter wrote: > Not to mention RFC 7258. > Well, obviously all the law enforcemenet actions are not pervasive but highly selective against legally determined suspects of criminal activity for whom then the right of privacy is forfeit for the subject of the investigation. So democratic governments would never do PerPass > > 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