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

Stewart Bryant <> Tue, 13 October 2020 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFD713A03F2 for <>; Tue, 13 Oct 2020 07:28:50 -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 VgX2paw7rXo1 for <>; Tue, 13 Oct 2020 07:28:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F94D3A03F1 for <>; Tue, 13 Oct 2020 07:28:49 -0700 (PDT)
Received: by with SMTP id n18so24330330wrs.5 for <>; Tue, 13 Oct 2020 07:28:48 -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=rUYASCvLjwShE0RA6N/wy1NYD2k9AnE90Ie1OafaK+M=; b=SdaMLTXk0nautf7BvZ3xz66tdECr2+HeLTumPQxoh3dIii77Q5CE15x7tC21RsVKNY eEoxuzngoElzMM/QRfuEWGuqapSMRlTDwAfAQIUD87tOB8WT2DoRZb/VuBso8ACaHW1f 4K/faeS1LckmvVsvglQ3m/DZG3/mGdI6RBnxTfITtRWOWpNikTE8CCod8AHc864jJDQz x5y7B0SjDUeZ7/8i976Zj1xW049aau+Rpqca2jBOXpUTb+rd71svzfBekCElSD2JtcxJ dRLhnGeEepfQVjLNbT2Al3nmo3y6GoEyWSuhPdMspya8P4JxTG1NzPcT83O/XZaAxWy9 wKjw==
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=rUYASCvLjwShE0RA6N/wy1NYD2k9AnE90Ie1OafaK+M=; b=PMj5LNGenDlbq3bWbkum4FLCL72rih8nBkL1jdhgvkI8BvX4em3HOq4hWHPPVqnHqD 5GdMFuC/HfvVSiDO7W+Jp8PWw7/TMlzn0rfUbQQS2s9qpibSG/Mo/rNhBmJLVlK4bit1 rdPT5KXehZVKf/eRaK1wJbiWJIj155CRtZeG3pcDZphEhJq4FoETB7ueNLnbHQxNvL8l uLl1c3MBtDxhbIV8fuNyVYnGY9zhqWFg4qD0Wx3xbGkqa3fTdRslUd0gfc35QsetX1JW qCC+VvsnMciVgVexVTKmxD7+BoTGmTw3GnPj3jx1pIA4o5srGaE6R26MX4kfvmLWq9iR YGjw==
X-Gm-Message-State: AOAM531Y6xfo1tHzJHHysAV7YurL+5wHKssxq3sMCCUlQ5M/UpHKDa9t nnje6SRd8fDVqxGG997NIuTMCbJrdFE=
X-Google-Smtp-Source: ABdhPJy9kadFKjOuWPZ5X6Sjm8KseVJnrLaGhkUDjJbFk0iaJL97fQOyAGM+LoK/x9lQmB1I8FMaJw==
X-Received: by 2002:adf:df07:: with SMTP id y7mr39474933wrl.347.1602599327476; Tue, 13 Oct 2020 07:28:47 -0700 (PDT)
Received: from ([2a00:23c5:3395:c901:5d29:86d5:3f0b:55d5]) by with ESMTPSA id y14sm48469wma.48.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 07:28:46 -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: <>
Date: Tue, 13 Oct 2020 15:28:45 +0100
Cc: Stewart Bryant <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <975E28FE326C22E8CD32DCC8@PSB> <> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <> <>
To: Joel Halpern <>
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: Tue, 13 Oct 2020 14:28:51 -0000

> On 13 Oct 2020, at 14:46, Joel M. Halpern <> wrote:
> Stewart, please do not describe this as "allowing people to do bad things to innocent people".  We are not "allowing"anything.  We are trying to properly protect communication, without regard to the content.
> Recasting it as the IETF allowing harm misrepresents almost all aspects of the problem.

Joel, we are the current shepherds of the base technology that enables the harm.

You could say that car manufacturers do not kill pedestrians, drivers kill pedestrians, but by governmnets forcing car manufacturers to change their design a lot less pedestrians are killed these days. So the question as I see it is whether we can do anything, even if slightly expensive or inconvenient, that mitigates the key harms.

> As for squaring teh circle, I tend to trust the many crypto professionals who have repeatedly looked at this trying to find compromises, and the many reports they have produced about it.

In 1956 we were not sure we could launch a satellite, let alone walk on the Moon 13 years later. I consider us to be quoting the convention wisdom of 1956 without looking at what we might be able to do in 1969.


> Yours,
> Joel
> On 10/13/2020 9:34 AM, 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.)
>>>> So the problem that we have a moral responsibility to address is to
>>>> find methods that stop or minimise those harms.
>>> I don't accept that. The "we" isn't clear, but what
>>> does seem clear is that meeting the requirements posed
>>> is (IMO anyway) likely to do more harm. I've never
>>> seen any proponent of borked crypto do a proper analysis
>>> of the damage that would be done - they almost always
>>> seem to approach it as mostly a PR exercise and so go
>>> straight to the "think of the children" and "what about
>>> the terrorists" talking points.
>> Well I am certainly concerned about those two groups.
>> So the interesting question is whether there is any other way of addressing the requirement without borking the crypto, at least for the majority of applications used by those causing the harm.
>>>> The problem may be hard but so were many other problems that we now
>>>> take for granted as solved.
>>> I didn't say "hard." I said "squaring the circle." The
>>> latter isn't possible and is much more like the "magic"
>>> that is being asked for, and has been asked for since
>>> the Clipper days, without any technical progress at all
>>> in those 25 years.
>> Are, but that is my point. Maybe we cannot exactly square the circle, but perhaps, if we look at the problem in the right way we can create a sufficiently close approximation that it satisfies the requirement?
>> Stewart
>>> S.
>>>> Stewart
>>> <0x5AB2FAF17B172BEA.asc>
>> _______________________________________________
>> Architecture-discuss mailing list