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

Eliot Lear <lear@cisco.com> Wed, 14 October 2020 09:10 UTC

Return-Path: <lear@cisco.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 B17B03A1422 for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 02:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 07EcRbZOMpkd for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 02:10:57 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE9A3A1419 for <architecture-discuss@ietf.org>; Wed, 14 Oct 2020 02:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14025; q=dns/txt; s=iport; t=1602666657; x=1603876257; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=enP42I6sLodqU7SlGByV5f9F3CYIqIPeq0SjeTvursI=; b=ABUDDmdMaF7DoDRMmKW2TJC7Qf/2sksPSagiaj73HDc+7eObHOLh9KsC uEtSDSDxm//o9AMxcmcE51hTo/9+klmKryn7j+puJB3jt1Cf3uWqpYS7C FtYmJFZ4kj6Sfv6R19CWwnGTW1/ubmvCehxi0ez3uXWip/9WI+nCTaoHT w=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AeBAACwIZf/xbLJq1gHQEBAQEJARIBBQUBgg+BI4F3VQEgEiyEPYkCiBeHZowmiBoEBwEBAQoDAQElCgQBAYRKAoIDJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBI1YFCwsYKgICVwYTFIJwASEBglwgD6dsdoEyhDsBgRiEcAoGgTiBU4oggV6CAIE4HIIfLj6BBIFYAYE3g0Azgi0Ekw6JBptWgnSDFYE3hDeGXIsOAx+SNo8MK51vkViDYAIEBgUCFYFrI4FXMxoIGxVlAYI+PhIZDY43iG2FRD8DMDgCBgEJAQEDCYwCgkYBAQ
X-IronPort-AV: E=Sophos;i="5.77,374,1596499200"; d="asc'?scan'208,217";a="30283272"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2020 09:10:53 +0000
Received: from [10.61.175.164] ([10.61.175.164]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09E9Aq1h003179 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Oct 2020 09:10:52 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <22B6BB6E-751F-4B27-9FF5-C47DFED4CDDA@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4FA73EDC-D43F-4DED-9C7E-42588FD08C47"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 14 Oct 2020 11:10:51 +0200
In-Reply-To: <c5b37390-d463-fa35-215b-569698098d6a@cs.tcd.ie>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Outbound-SMTP-Client: 10.61.175.164, [10.61.175.164]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/4zD35UlVHk1OKltH8bnXBFaOuJI>
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 09:11:00 -0000

Hi Stephen

> On 13 Oct 2020, at 15:17, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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] https://carnegieendowment.org/2019/09/10/moving-encryption-policy-conversation-forward-pub-79573