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