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

Andrew Campling <andrew.campling@419.consulting> Wed, 14 October 2020 10:41 UTC

Return-Path: <andrew.campling@419.consulting>
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 BFA3A3A1483 for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 03:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 feySKe6kbqnc for <architecture-discuss@ietfa.amsl.com>; Wed, 14 Oct 2020 03:41:15 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100050.outbound.protection.outlook.com [40.107.10.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2DA3A1484 for <architecture-discuss@ietf.org>; Wed, 14 Oct 2020 03:41:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cf8NcxdoWDx2ZYPt1FOatj6++5DSniRz7QhV56CpCorQHvqXdcwvaa4LNRv74g8aTXrFVWqbq1WRZ9mhylWv2NAWLaMDj/0CpX5HT9a4spLWkfpXyXZU0hmp/loIsYjt57yo0lGeUwAhccA8JofiqAY51GnvbBfNW52gpz/yDAstFjezYf9jOPiGjMJOUFTsM9r3SZg5+7AkOKan/cKoFeL0YF3/6v213FM+ZKN6xieoKdjUA458MtV6jcryLlVa5AzRb4vZEf22EXS0kuqoIgZZu7TUJughxRm2yK2/jPVuAYhhigMZciY0lkVKdHOb96h+I2tWsZB9z7As/nfjyg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z8e9vScNfs/yJUpFpL82SEeaqQheI8XGnwQw2vGI5q4=; b=AP3nQ7bbeI0Z5denGt2cLgbiTNF4K21ulH8aRcGGsdaiDUgQJKHurA00KwvrZzmLHEduogC1+3KqdP+OTMa+d+YEfpJNGqjIXVIKvPUxA/1gsetyUgL5Ft4KkF5/liHEBUxpxHqOWhq7Wi2Nl4kJajUNfaAvpbJRbzdTPrwCjC1o1e6ZkFoSUdWHlponP2TDIdFHQ+9451i6XEK1gNQU6sJu+Y9TLllZ0+eV4uoNLD99V1MwwggZgYbkuMd9jJkq4N4IrgpX72lj1EwxRN4yKD2zCGH7iLA+JyJ+huFOXSUfN7w7fXfsBDVFPtmUHeF4qQPLlkXsu25emhcJmxl+1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z8e9vScNfs/yJUpFpL82SEeaqQheI8XGnwQw2vGI5q4=; b=SFxqytwn294jljIoqDjGGteV5CAXnsNdbVbrOHJxht6XoYmnZ4ctWyhcbg8K+qtJF1C6Ljyr71ZBJJzlg6PdTXSHPcdTNUQxeoMMDQLEt94so1ri9t1+w1MrDR+mqB/9Ul8VpNsLPLNrzn+vhz4rr9uKEc5sARftUTTQOCymm8M=
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.26; Wed, 14 Oct 2020 10:41:10 +0000
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::199b:a430:6264:9bf6%7]) with mapi id 15.20.3455.032; Wed, 14 Oct 2020 10:41:10 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: Christian Huitema <huitema@huitema.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, John C Klensin <john-ietf@jck.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Thread-Topic: [arch-d] Time to reboot RFC1984 and RFC2804?
Thread-Index: AQHWoMn9j99I/MmCyUqbSc1JabcsyamUdupwgAALGQCAAPrOAIAACAoAgAAEyoCAAGnvAIAABc7wgABGCwCAAKFVQA==
Date: Wed, 14 Oct 2020 10:41:10 +0000
Message-ID: <LO2P265MB05732E22C376062F808746E3C2050@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
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> <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com> <e29dc18a-fd5d-ca0d-90a0-4ec840678054@gmail.com> <LO2P265MB0573F23F5C23ABD3933E49FDC2040@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <d5921a18-1cd4-5eea-ff96-70090680b54b@huitema.net>
In-Reply-To: <d5921a18-1cd4-5eea-ff96-70090680b54b@huitema.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huitema.net; dkim=none (message not signed) header.d=none; huitema.net; dmarc=none action=none header.from=419.consulting;
x-originating-ip: [81.141.77.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2b06528d-4135-4e7e-6e60-08d8702daa66
x-ms-traffictypediagnostic: LO2P265MB0573:
x-microsoft-antispam-prvs: <LO2P265MB05735461B976F8A98140EBAAC2050@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: geiqnDf8HpWPZ1NSOw4sTj7JNwUfmkpe/s4DoXd9K79gbIVG5WbZnqplzBcoWpTJWApqxfZgw8bpUkza65x7jSXUlaSgnjpgvLliEsEZCj+M3aIR6j71BCc2thFQwyUZvzwWj5CKPQj18lptNjPpqdcjoiNcNPDYYh1KZdP9sYE1nbJKhbjjVhg/QmQh2sJElykaGXRnmvktPl1LYvUP3JyV4OEjp1dX+wKQVSxST6XcyeEnaLXElze8H2NMuSzcybv3wiSpR90aJvExrbvMyJliRii2sHZ2qwMBSSr50rDVTeuLvdQjghqxmOPrFok3LLQWVPCufbgAdPDdjw2jSJhjjQInGxnsHQaMYMXWJ8I/0sasUjoakOLuxo4bnxBP
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39830400003)(346002)(136003)(376002)(396003)(9686003)(6506007)(33656002)(7696005)(8936002)(53546011)(26005)(83380400001)(8676002)(66574015)(4326008)(2906002)(186003)(76116006)(478600001)(71200400001)(66946007)(66476007)(66556008)(66446008)(64756008)(5660300002)(52536014)(86362001)(110136005)(54906003)(55016002)(44832011)(316002)(46492008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: iHDEOUYXrPE/q3czOqdy0SmjaKCfpGcgYYKasrYDCMzBdQbNe5jTp0E8Gr8gYX2quiUNzg0X7Ym4oFGLbk7yhi9WcI8c41SgqayO4zURr1hfj2oH4WM+O3tyBU3esotYkxnexSP+KU2mMfjQmOVtspiuCb/mHruLvgeMWKsPfEM0tBZRJCVFyGwhtIS8gHygQbjh3EKIVdKO9gvW4xtp8FnJ9HnU5Mb/61hrIbvWQmvR898k0jcQlX3FYvvSHFldqmJhTkNP5/B8IzYe+oJLx9osV2yPlaKAVXpOyrNghwF5nMgQzHnF1NyFfVmn7CCEdJqhgQtk/OtYhlsX5Unl2hhwwBYSyCWkAQR/+5C04iO9W9uwjMdlFKyIXYLrCtLYu6P6ovS8fv44W5nEtumWT3GQ4y1U5X/Mb1BGg7zadwJ3hhfvCbPqz8UJpBxCGk4cdsrXgcO+Jdrv5uS9nhT1smyO7BNuQSdbTWROvN7GYIqkj8Llhfb95dseRyM8jCZ5g4XPNyr928+rHnak7JE4jd/0jnsG73C1FPycKFzSKEeFKrfxaux02CbFg4zvnA0Dqz5ETd784lHsRIz4f/QPpEs+9/pw5cunGMpGG5QpAsxCQzOKB9MTrjYisVcKu7nmiJbY48wgyHFJ+4RApWj08w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LO2P265MB05732E22C376062F808746E3C2050LO2P265MB0573GBRP_"
MIME-Version: 1.0
X-OriginatorOrg: 419.consulting
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b06528d-4135-4e7e-6e60-08d8702daa66
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2020 10:41:10.6004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gikW4h4qaLTpDKx3ltbZ0tXXR02U4Nwj6SzNNQzsPWE5PAEPZa08wlvrPAgNvNF+hzT2Zn0lnVcMwsZXqeqe4aKPPQ3AaLCxoPDQOent58g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0573
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/hdDKBCDSWN5TuQ5qa6e5fkhztCg>
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 10:41:17 -0000

On 10/14/2020 1:25 AM, Christian Huitema wrote:

On 10/13/2020 1:33 PM, Andrew Campling wrote:

On 13-Oct-20 20:54, Brian E Carpenter wrote:



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.

I think one of the challenges here is that there are no easy answers - if there were then this particular issue would not keep coming up.  We have a conflict between preventing harm by "bad actors" on the one hand and protecting privacy on the other.



First, let's agree with Brian that the IETF is best at solving technical problems. The kind of balance that we describe here is a political and possibly cultural issue. It has been solved in the past in adjacent domains, for example with habeas corpus, innocent until proven guilty, or the prohibition of torture. These are widely agreed principles in democratic societies -- but not necessarily in all societies. And these principle do recognize a balance between good and evil. Stating for example that society would rather have a culprit walking free than an innocent in jail is an explicit choice. I wish society would be able to make similar choices regarding the privacy of communications, but this is definitely not a technical issue.



I agree that the IETF is best at solving technical problems and note that it has previously determined both that end-to-end encryption is the correct technical solution to protect privacy and that privacy should be prioritised over at least some other considerations such as the significant harms caused by certain behaviours that have benefited from that encryption – I will desist from giving examples to hopefully avoid this becoming an overly emotive discussion.

I believe that there is a case to make that the current direction of travel of the development of the Internet, underpinned by end-to-end encryption, centralisation etc, is having, and will continue to have, consequences that are likely to include further fragmentation of the Internet and a loss of the desired privacy.  Some of this is addressed in a little more detail in a short submission for the IAB’s proposed Covid-19 Network Impacts Workshop so I’ll not restate the detail here for now on the assumption that the paper will be accessible shortly alongside other workshop submissions.

I therefore respectfully challenge the assumptions: (i) that the status quo is the correct and indeed only technically valid position; (ii) that privacy is best protected over the long-term by end-to-end encryption; and (iii) whether privacy should be prioritised over all other harms affecting end users.  In addition, I challenge the presumption that the IETF is the only body able to make such a determination about these matters and that it can and should do so without undertaking full consultation with other stakeholders.

It is my view that these three points warrant proper evaluation that needs to be undertaken through a true multi-stakeholder consultation process as suggested by the IAB’s RFC 8890.  Let’s first prioritise the harms and agree how the Internet should evolve *before* determining the most appropriate technical solution, the latter task in particular being proper to the remit of the IETF.  It may be that the outcome of that process is that the status quo is in fact the least worst way forward but this needs to be properly tested rather that stated as a fait accompli.



Andrew