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

Stewart Bryant <> Wed, 14 October 2020 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A10BF3A1438 for <>; Wed, 14 Oct 2020 02:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 RLLO866HwMqt for <>; Wed, 14 Oct 2020 02:54:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 710083A143A for <>; Wed, 14 Oct 2020 02:54:18 -0700 (PDT)
Received: by with SMTP id n15so3049174wrq.2 for <>; Wed, 14 Oct 2020 02:54:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iHclTP0ikl6Cwz4ITJDDn2F9Ml1yvYukobGdbbkPx/4=; b=DrvjpWScoGzoMdiAZYahkWu7VMMWg6vhbEYpitY8omGoIBs4YIZzKY3OWTLr9QLi59 rIPvvsGxop8R1XfQ1ith8BcnaGarpOr2IxT7sX9RYDzkkLNSVTXT2NM+3GWn/0SVp9NA LrFCI5A+CvAfs4OAWMPxVltISUzY242tMFHW20MtJSwpwEju8smyFZpNLwXrb/+u5HcJ LBYHzPinV59Wy7GXgqJI6jLMnUy6Yb3H7eVkIfttOd5KIKalBskVIdULTqf/4tUUwx2D IMug58FeBd0HdEpjq8jhX98rlPsu1ezq6ZFHNTLTMwbs8KBXauBTRTBhRkN2+2jqSKAO BUtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iHclTP0ikl6Cwz4ITJDDn2F9Ml1yvYukobGdbbkPx/4=; b=KdjkWE/XPgG/MeKigvt7hEL/Js7+RYZXv+tJETf+7YsJU38j7rT2rkD6pPjjL+kP8P ATMeTaWM9FT+7aqe2KexJM0jXu/3ibJRvLuVeKyfeSE63HHHENfMHbifH+39VTIq3967 nlFnoP+V22e0UbDhG4twA/fh7ZbtAvbqrxsoC5kDvAEIP2SGf7Yv62Aww8LHVe9VY3Jk 5z369dbF84M8Nzh1ypgdmPdSvpqKPXAGlAqk6QsurHO2LWqlMcix/kDF8JC6suYnQ18a rGxnrNQ+NUqyXqj0tbx0zNHfuWdvZEqSZM9Ajn4CamQnBiuLjd6P++eg9G6VNHNGvnYO pSnQ==
X-Gm-Message-State: AOAM532Ws6cvwrGN0i6mEiT4Nl+z4e7I0bPbM8m3zepucNstO/+9o5B/ TYdu9ngcxYns5yoQCpxxtCg=
X-Google-Smtp-Source: ABdhPJz8QJrg2PQ7nT1fj4Pswk3OROuA9shloMMzpN3yfEfrjptbAGavwP3KXC/laiSRq5zStNI/Xg==
X-Received: by 2002:adf:dd8f:: with SMTP id x15mr4840918wrl.124.1602669256635; Wed, 14 Oct 2020 02:54:16 -0700 (PDT)
Received: from ([2a00:23c5:3395:c901:e5f2:3008:db5e:7e5b]) by with ESMTPSA id c21sm2862147wme.36.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 02:54:15 -0700 (PDT)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_590FD4B2-C5F9-4C5F-A72D-C444324A7268"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 14 Oct 2020 10:54:14 +0100
In-Reply-To: <>
Cc: Stewart Bryant <>, Stephen Farrell <>, "" <>
To: Eliot Lear <>
References: <> <975E28FE326C22E8CD32DCC8@PSB> <> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <>
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 09:54:21 -0000

A good summary.

- Stewart

> On 14 Oct 2020, at 10:10, Eliot Lear <> wrote:
> Hi Stephen
>> On 13 Oct 2020, at 15:17, Stephen Farrell < <>> wrote:
>>> 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.
> There are (at least) two threads going on here.  The first is what the social responsibility of the IETF community actually is.  The nature of our work has always been dual use.  Crypto is the classic example of that.  We have to accept that.  But in so doing, do we also have a responsibility to ameliorate risks or even articulate them?  That’s not to say that crypto is bad- it is a foundational technology without which the Internet could not have grown to its current size of O(10^10) devices and over 4 billion users.  I do think it’s reasonable to evaluate the societal impact of our work.  The hrpc was sort of a nudge in that direction, but very small one.
> The second is the risks of having these conversations in the abstract.  That generates more heat than light.  When we talking about “borked crypto”, what do we mean?  Do we mean algorithms that are weak?  Do we mean key sharing and escrow schemes?  Do we mean something else? I like the approach that the Carnegie Endowment committee led by Steve Bellovin and Susan Landau took in dissecting this problem, in order to find starting points and common ground with law enforcement.[1]. But even that presents challenges.  It assumes that there are, as you more than allude, a limited number of well-governed actors in the conversation.
> I’m not taking a position on updating any documents, but I do think it’s good for us to ponder these questions as we consider new mechanisms.
> Eliot
> [1] <>