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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 14 October 2020 07:43 UTC

Return-Path: <stewart.bryant@gmail.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 5A4633A13E8 for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 00:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 s0dxvAnMfGvs for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 00:43:01 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD863A13E4 for <architecture-discuss@ietf.org>; Wed, 14 Oct 2020 00:43:00 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id g12so2509479wrp.10 for <architecture-discuss@ietf.org>; Wed, 14 Oct 2020 00:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pzVPMQTOGHMyx8SbVCVfnDB7oCVskO2OePXnbWtq1LU=; b=HhDU7UFWyizs9kqSaK2O91ZXbAPaD4aADHZs+88wipmQyNmYHRSql8TGqKAZGO9a7r FKks5pV4Y+2qPbQ3dtoDb7AIJpl90YGjXLeqkJ2uydKjzg7B1gDh10aibhc1FhhrB/w9 HaEFvd7v1vR+Kkb6kk65I1WuQO+WyEZw1a3mz6dPG+NrRRL9Ooveq3wcoqCVLrAx6G9b 33BFe082MQrHPYNvWM/uFYDdoVpLystQKBLqSXwpDQBvQB1AgioIFdRkB/Zb982j7BL7 D/uliH7848bBlqQOfGCZAOSxwP09IcRGIOuCP5a7MnEXnRTuoH1tZUjob3WyM7XhYAuX K5wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pzVPMQTOGHMyx8SbVCVfnDB7oCVskO2OePXnbWtq1LU=; b=fDvp0DwU8dBT77q+J/pae+G+Bm9deMkjrwPEs4iIm0sVqHBCQRMVQ72pEJhaApzeKj dQaJlJdCYC/vJNRRsnDOtcigwCVwcrJNhNR1tUwCI+EZtpEZ/KA39GwrkcAmOPtKGkA7 rOwKMFhhdlcsdYHdAtVWKoieXMWBdYNA6+Viuc+zccf/E/xXXB8Ta/VH2Blb54CjpcMQ xmr96zf1TOn9bqF1YGGlQwlmzMGQSw8r/7SIJq3w/r67laE6KtDeWv7KtUJf9Ejz3zUm leySvMGIsxZq/SSRZ2W1ocGciEgKUAOZ2Umfo0497V588Ozrsof5zwmO2o6nSB/vOJHK jUHA==
X-Gm-Message-State: AOAM531n2FFv91nT/VKF/AT76/wmGtkzHAB8EmJFK6vZyfLKEWbbHtph a69XQtfp5F/75qm9a8e3UA0=
X-Google-Smtp-Source: ABdhPJwxndE2SWXOgPfK0LNnr9kfcJS1Laz+T8dkJhP45eLJBfp1+U3xwNBqaq7ghSUD3Tsflk6LCg==
X-Received: by 2002:a5d:4fcc:: with SMTP id h12mr4135984wrw.132.1602661378974; Wed, 14 Oct 2020 00:42:58 -0700 (PDT)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:5d29:86d5:3f0b:55d5]) by smtp.gmail.com with ESMTPSA id 40sm3466792wrc.46.2020.10.14.00.42.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 00:42:57 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <1AAC6944E2F493C97D78DD3B@PSB>
Date: Wed, 14 Oct 2020 08:42:56 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Andrew Campling <andrew.campling@419.consulting>, Christian Huitema <huitema@huitema.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A818075-52FA-47C5-9087-6EB5665D4C51@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> <1AAC6944E2F493C97D78DD3B@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ZJPNiXv2S8rLdx4qbFCGDBMp8yI>
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 07:43:02 -0000

John and I are largely aligned, although I do wonder if it is technically possible to provide a method of providing access to clear text in such a way that it was safe from anything other than through the cooperation of multiple independent trusted bodies operating within an agreed international legal framework.

Stewart




> On 13 Oct 2020, at 19:00, John C Klensin <john-ietf@jck.com> wrote:
> 
> --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
> 
>