Re: [arch-d] Time to reboot RFC1984 and RFC2804?
John C Klensin <john-ietf@jck.com> Tue, 13 October 2020 18:01 UTC
Return-Path: <john-ietf@jck.com>
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 788763A0E25 for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 11:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnbraNpm_Vea for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 11:01:09 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8844D3A0DA4 for <architecture-discuss@ietf.org>; Tue, 13 Oct 2020 11:00:59 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kSObV-000DDp-5S; Tue, 13 Oct 2020 14:00:53 -0400
Date: Tue, 13 Oct 2020 14:00:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: Andrew Campling <andrew.campling@419.consulting>, Christian Huitema <huitema@huitema.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org
Message-ID: <1AAC6944E2F493C97D78DD3B@PSB>
In-Reply-To: <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com>
References: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com> <975E28FE326C22E8CD32DCC8@PSB> <5021a377-e9ca-1580-c2f0-3351b9f5fe04@huitema.net> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <e80b6f1e-3949-b2ee-6e61-a2f3dfce9b0c@cs.tcd.ie> <586DC363-B5F8-4727-8734-815F3E17F345@gmail.com> <c5b37390-d463-fa35-215b-569698098d6a@cs.tcd.ie> <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/mMVZAK4CCdzRkKAj3AS6sWEr0bM>
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 18:01:17 -0000
--On Tuesday, October 13, 2020 14:34 +0100 Stewart Bryant <stewart.bryant@gmail.com> wrote: >> On 13 Oct 2020, at 14:17, Stephen Farrell >> <stephen.farrell@cs.tcd.ie> wrote: >> >> Hiya, >> >> On 13/10/2020 13:48, Stewart Bryant wrote: >>> >>> Stephen, >>> >>> Those governments are looking for ways to stop real harm to >>> real people. >> >> Some are, yes. That is not all they are interested in doing >> of course (they all do like a bit of spying here and there:-) >> and all that varies enormously from one to another government. >> Some governments want these changes in order to do what I >> would call harm. > > Engineering calls for a pragmatic balance of results and costs. > > From where I sit, I see a significant downside in allowing bad > people to do bad things to innocent people. >>> We have to accept that we have unintentionally played a part >>> in causing some of that harm. >> >> And a lot of good. IMO, on balance, and after having done >> this stuff for >3 decades, I'm happy that we've done overall >> far more good (with crypto in protocols) than harm. (That >> doesn't include surveillance capitalism, but that isn't the >> same issue.) But unless we can figure out a way to make that distinction a lot more clear to those who do not share the same technical, economic, and political views, it is not clear that there is a difference between "surveillance capitalism" and assorted things you consider "overall good". Not disagreeing, just pointing out that such distinctions are not universally accepted, that one can favor availability of crypto in protocols and still want restrictions and access in some cases. I can't tell if Stewart and I are in agreement or not, but all I'm suggesting is that we need to see many of these things as relatively complex systems that involve the policy-makers (however clueless, friendly, or hostile one might consider them) as well as the technology. That means doing a better job of looking at possible tradeoffs and then being explicit about what they are and what choices we are making and why. If there are different types of attackers and we can optimize for resisting one type and not the other, then we need to get that out in the open and be explicit about the decisions or compromises we are making and why. If both "more concentration" and "having things more widely distributed" have things going for them, then we need to look at how to balance the two, not just denounce one or the other and pretend there are no side effects. As an important example, while the message has been clear from crypto experts that there is no way to build back doors into systems and avoid having those back doors create vulnerabilities, "we" may need to think more carefully about alternatives (technical or otherwise) to explain to regulators and legislators. If they decide that something must be done and we convince them that, e.g., law enforcement access to encrypted streams is impossible without creating larger problems, they will (and have in the past) consider banning crypto entirely (something we all agree would be a bad outcome). So, when I first read the subject line and first part of Brian's note, I interpreted "revisit" as "maybe it is time to move away from the absolutes of "doing that is bad and won't work" or "that is an evil and will hurt the Internet" and to start looking more at why others might think that a particular approach might be worth it despite the disadvantages, We should, IMO, be willing to look at those issues to see if we can find alternatives or middle grounds. >... john
- [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