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

Stewart Bryant <> Wed, 14 October 2020 07:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A4633A13E8 for <>; Wed, 14 Oct 2020 00:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s0dxvAnMfGvs for <>; Wed, 14 Oct 2020 00:43:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFD863A13E4 for <>; Wed, 14 Oct 2020 00:43:00 -0700 (PDT)
Received: by with SMTP id g12so2509479wrp.10 for <>; Wed, 14 Oct 2020 00:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ([2a00:23c5:3395:c901:5d29:86d5:3f0b:55d5]) by with ESMTPSA id 40sm3466792wrc.46.2020. (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.\))
From: Stewart Bryant <>
In-Reply-To: <1AAC6944E2F493C97D78DD3B@PSB>
Date: Wed, 14 Oct 2020 08:42:56 +0100
Cc: Stewart Bryant <>, Stephen Farrell <>, Andrew Campling <>, Christian Huitema <>, Brian E Carpenter <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <975E28FE326C22E8CD32DCC8@PSB> <> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <> <1AAC6944E2F493C97D78DD3B@PSB>
To: John C Klensin <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> On 13 Oct 2020, at 19:00, John C Klensin <> wrote:
> --On Tuesday, October 13, 2020 14:34 +0100 Stewart Bryant
> <> wrote:
>>> On 13 Oct 2020, at 14:17, Stephen Farrell
>>> <> 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