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

Brian E Carpenter <> Tue, 13 October 2020 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FC973A03F4 for <>; Tue, 13 Oct 2020 12:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, 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 ghvkLmzcRIAl for <>; Tue, 13 Oct 2020 12:54:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 158323A00C9 for <>; Tue, 13 Oct 2020 12:54:02 -0700 (PDT)
Received: by with SMTP id j7so358477pgk.5 for <>; Tue, 13 Oct 2020 12:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uPLfFEVwZ/zihM5rLSH4yqr+2eJqYuVWWXbYx3+xUWc=; b=iTFD31zfDDRhSnAQwQ1ZbRdPBJEgpJFpaZhnk9tvc4CNSIUs+sNn1i+ptZ89t0GP00 UN/BaxQj1B9vhsrsIHKzciSU0SuwmuZSbIS++LabMyEyFjrJ/XUZVu1bnF6uDtcg1wdP oBdfCw2PWArqKT2fyRlv1zuk5bjuXG9hoalNqMsRXGRvUuWgizyItdGg2k40AIvCNIv+ 9dDv914FAEXNzawLnn3UTxJS+Z+GcJB5V6blXKQNoDx0acKQfC85xASPsa0pkPMqX2Ew Drv28+tRh3hsTH4gtdmid+xPuVo8+C0WqQWS331K+s6spdGA2AcWl91nDAlCtN/qbyCH FKFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uPLfFEVwZ/zihM5rLSH4yqr+2eJqYuVWWXbYx3+xUWc=; b=LQV10H5UH+tYtCKKH39GDKFASWvJKRC/qJsBZ+jajuqsd26EzVHvr//iBGlKZQkLKq 0W2YyoyBP7GTTRas6HdHXuc9M4LU3QYclUoWAlGDZSLa8EwAvXgo1Qno4G+nMCNVFRj6 d2Xccd4mzw5J7LRfwGlQpnq8mTfgbXu+BuVLY8RkQVJeIX8dzS4n0d1M3wiSYhcuY95D YXanbTS0KVfaOwD5cr9NNhbjVeua9aBfnUFD7qVas//yACPNxNcIneRDsArbecVdG0kV T4MQp/KDTBkFjBK31umpj/K5+7/VHQWG4yi9rX2tpkvSLVbEHbW1r6BbWC2KkPYRX/3Z ZZcw==
X-Gm-Message-State: AOAM533rMpqoJG76KOr8vxrZRpKCo5fvOAjldvPr51PfyUYtEeYXFZsc EWUIJXxyfWW1jYTHRjrrGG0uLzYdunPVZA==
X-Google-Smtp-Source: ABdhPJzpBB02nJYmbu+OTqSeAeXK0Rbzmvyc26Amn38R0sD/mQu9Eveek8Wtwpr3VUJUZA4m2jn5+Q==
X-Received: by 2002:aa7:9299:0:b029:156:5edc:a506 with SMTP id j25-20020aa792990000b02901565edca506mr1270784pfa.52.1602618841022; Tue, 13 Oct 2020 12:54:01 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id v3sm10050pjk.23.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 12:53:59 -0700 (PDT)
To: Stewart Bryant <>
Cc: Stephen Farrell <>, Andrew Campling <>, Christian Huitema <>, John C Klensin <>, "" <>
References: <> <975E28FE326C22E8CD32DCC8@PSB> <> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 14 Oct 2020 08:53:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 19:54:04 -0000

Hi Stewart,
On 14-Oct-20 02:34, 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.

Please explain what has changed in the fundamentals since RFC1984 and
RFC2804 were published, and what *technical* errors in those documents
now need correction.

We all agree, I think, that many bad things have been done using the
Internet. How many of those were done using cryptography, and how many
bad things have been *prevented* by cryptography are both objectively
unknowable. Therefore, we simply don't know the balance between good
and evil here.

IMHO, we should stick to our technical knitting, and that's the basis
on which the above RFCs were published.


>>> 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>
> .