Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content

Andrew Campling <andrew.campling@419.consulting> Mon, 18 December 2023 10:44 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 53FB3C14F685 for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Dec 2023 02:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.129
X-Spam-Level:
X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQXfLyt5fCmg for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Dec 2023 02:43:56 -0800 (PST)
Received: from GBR01-CWX-obe.outbound.protection.outlook.com (mail-cwxgbr01on2081.outbound.protection.outlook.com [40.107.121.81]) (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 3C7B3C14F684 for <architecture-discuss@ietf.org>; Mon, 18 Dec 2023 02:43:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y9tqjKOpMJcJACamkRWBCIr2AmC6MHuDmpsUL5P2SB5NTPcJHvWvQoQ44wwDmYDDJyULmdIC9IBFTOc5M3/OrioXHG2Db3a3wCAL+PQY0+KHAmvhjkFNiAl0VXSz8AVTA+WM2Qr2hLIlNrIY/X+DB3qYBQX7nwEPgD8uO6838rlUNRLnFFUWHt/0G2aGvpMYAD5IRXlyAD972Yq0DSIAAl+rzz5tKitntuKYdm69GD1NKZtISVLGxqVPm1HJ8I+484JCKPP2/MmIF5CUkKHXdsVzq/lUFgbxTc58NrmL9iOF+HJ1dcSvphfGfXPn9Y8K8yEUxj9nnyjlhEAKEkqOjA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i913DCVwP1C+f9YcQ2euJxxI6/GqfWpVjNx5U/z3EZQ=; b=Y4ArhCp3HerSzRcvZfBGuI92VR5Ewcl+2qFz0RqOmpdqt6QufiPUsvmQ5HkrYJyViynrR4caik4q7CDNeTiJhyoQLA7mlORE9huLvTVD7iMJw2dlaW2sE71uwdB3l07v8qnJpep0mbp/gey9BbDfCiSfKF9PuLKvkKLOPRGscJu5dTqa4AsizZZ98QCtSuFaSQVyOawUEkCtvWl0NMgyGRVgSY8TFOpKRgH7TtinrxndtLaHilQaBK6fjWPyutN1zDn/cJdQvUMAzmHpPfmCMj3h2egM9DJiD1+Ioqo+UA4QALI7abZ8intTolB9Ip5C17p8dNae8HXRuf6Q+gAgZQ==
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=i913DCVwP1C+f9YcQ2euJxxI6/GqfWpVjNx5U/z3EZQ=; b=TFjidOV/xYQXBgj8aPR5ETSmZrbydV18BGNE2DVqOwNxMYk8Hq0TZRXZ8XMSuhMi64SHF9bTkDXwoMS9TSPVIL9qx1g6kZeHScZjR8du6IgB0rYTUHmSTKpoSikzx+PJRlHV4eXwGJcPHiAhUskhAH+0ezq1+fAkCsyakjYIIeQ=
Received: from CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:196::5) by LO2P265MB5133.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:250::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.37; Mon, 18 Dec 2023 10:43:53 +0000
Received: from CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM ([fe80::18dd:1afd:740:1278]) by CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM ([fe80::18dd:1afd:740:1278%5]) with mapi id 15.20.7091.034; Mon, 18 Dec 2023 10:43:52 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: George Michaelson <ggm@algebras.org>
CC: "iab@iab.org" <iab@iab.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, S Moonesamy <sm+ietf@elandsys.com>
Thread-Topic: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content
Thread-Index: AQHaMSOimVbsdaqogk+xffNwmDkfv7CuLn0wgAAvIYCAAGjRkA==
Date: Mon, 18 Dec 2023 10:43:52 +0000
Message-ID: <CWXP265MB515381523714FF99524410CFC290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
References: <170266952162.33107.14325064798861197261@ietfa.amsl.com> <6.2.5.6.2.20231216110256.18d0acd0@elandnews.com> <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CAKr6gn2Hf4N+DgKHKyO+i3T3OJyYRBJhH1AdQf-uXZ0xKmJ4Eg@mail.gmail.com>
In-Reply-To: <CAKr6gn2Hf4N+DgKHKyO+i3T3OJyYRBJhH1AdQf-uXZ0xKmJ4Eg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=419.consulting;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CWXP265MB5153:EE_|LO2P265MB5133:EE_
x-ms-office365-filtering-correlation-id: feeba3ea-7be8-4bbc-16e0-08dbffb63a2d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zZL8UzBs1MwAN6nZPP6e0GNFB0ylXUBrxL4Dri1NUbbfwQpH2EsUd3rskmpIkUzV/W0YU1M0okO6feRgMY2nhri1iNzsplm+42TNjfQZXm7CAT9hk6kKrhFaXVm/UVHCCMBtTzUH9DQWxvL7SSY1GU/Jo780Obrfv57xeUDeSbQdNdKcpbZPRjfHB+RIZMog+8dDvexdaarkvXEH6aPyXjuT/LlJ2+CgFMxbfIAlLjQdxuy5HRXZqfEgJFC0Ijzt3YppfyRR3SNfAO88x4i4VyEX5DhHhzqwFMJIZjaKBLdVGStpjbfDwDohcIIoSqhQPSddrixkRx1ihmr2E6hBKdeXbRvKnOuHFgE+fTpaaAAoL87KvhCaYz8CUy2Sr8Oc8YqKa7qxiPOoSnW3vI5lJoRkNmyPqSHhiHsUA2yMrLQW1Fu9Fwc1JSauOevCiZDIR+DuQT2D7bKpE4/B9Sri4l0Jh3gP92pQriqVHi36LUviXWGfPKPy8TNwaR1o3d6lm1eQ5m/oAajcoSuJSoIxCpkNWZAknhwickwAPTlTWOH1fSBqCips7cEt8ikdatac/J7/bXb53pFMAdFgrLCsZpZ6F/esWH+hXirc8M4S9AE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(396003)(366004)(39830400003)(136003)(230922051799003)(64100799003)(186009)(451199024)(1800799012)(55016003)(66899024)(66574015)(71200400001)(122000001)(38100700002)(33656002)(86362001)(38070700009)(83380400001)(44832011)(52536014)(5660300002)(9686003)(53546011)(6506007)(7696005)(8676002)(4326008)(8936002)(76116006)(66946007)(66556008)(54906003)(6916009)(66446008)(64756008)(66476007)(316002)(2906002)(41300700001)(966005)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: D6IAvYaEIpMbAXfiqECH90uXszgjWkYGm7pBiPR5f4OPwgm1D/cbgbsYaQZURp7Q3DrITq+lfL+34YFaLP7I0E01IiYZ4yWduObIR64rKh3Uvg+Xs56mnN8RqP18QeXgTlDQCU+l9h3pVO1jHzFRKZgnPiRi6vrr4+zG9xFwCD9Pe+zLgXwQT/yWg4XmuUxxw3HydD1Sj3rKvw2T4fGPYQkRq59DQ/2ghKkjm/WGq3apnvfEBKXcw+xfNH51jrJm37+hArpWcrKoQKjbNm4OxnXYC9VJp8RX9ygyrLQahjr8CsqhyCS4E9MWt8skLj/LLoTu9t4CkNtKpJuazgiE0zwg8uN6Va1f77ubWuszKYJJyGGoBsvWIFlZASkhQlf76E5VnY5l962mV9YNMJ9k9g5EdfA0OC6tp5P/SqQosZlIE25CTiq6zI/d3tMBNggmrCjnhAnxPvpFUIypJq0HxkfFCjgVIPTifKgdOtuBGu8WLV3KOWy8d6FtGIhhSwgNyXPF2bPioS6Aj9klii0ueREz7xUCXYzxK04LxjTiNRsLJ1qpkltz+VO2xxJu+SlthTcjUYKDLcbXuItTyvVpByEwSlzuohZn1iGd36t08p4dR4TgA774DUbS/KF9eSl9ZR8RVrWoMIe0aFNUTjTQKAejDmblcnp8VORn0ukcSB9hqK2NDkPlmxx1xid9KGJWLVx24/11XN3qhw8BLwHId9viDvo3kj75tubSZb7S8Lvu1YUl66gFp1r2Qr5qB0wChomy24gAxGZZKaUn3Dyy9Jg5OXeSID6A8yAxET0H0+YI1XbBMIIdO+Tc0fJpHC6VjFfrxCnXC3m4TfS3pV/KG4zGRoyD00YHXV22uHNKyqAMdxjKYCIYS8D0DtTIjo2ax7hJNrvR9aSkJBFS9CPFMibgcahf95y1UQZW5RSFJiHn2KoUar2f9BPwbAlxjrOnlFtHHGRvp+9jLRgfXGR+LF6fd4IIVAuXV3UzEx9Wyu6OX/vndTY3GF5XlQ6VZqyYL/ibkmSGg9vKR1zF5hyuTuGxRbk8gSshNm1Th/u9DEMPF8aZCdG73c9h4Jxb/x2U8XJl00sgxJE7zKPr3ofTMwlLU4bvce0U/0OD7NHow6jeRkSmjXAkbRmOFY8gPVVs0arjJd8OGDMLkPM3iAI1SJYyFbhdm00XtBVn2UcV1o6KYpNPKP3Zlx3Mrwu4pZ0fflsz3Dp721KZ/mctAcXFrlNCE5EGxuWRJsG62uPtzb9cPIr+Jr/ukeX/nuzeLlIL1uyhNZ1H66xyulUwE1Zl5ZycfHdHq+cFumcJYzPt4eutMMtvXtwV9uucAQVQeLqU1m5plYFcSbI5EeXBhC5+oQd24yivMt15iwkoN4Xp5YOpB5NktcQ9+RXCdNCAU08xDz5gQ3bVm5MCFSuQW84BHerVKC5WJFWmyTFdnxFOIzIjimYgK4GGyKfny0xdeeznKnvFZ5YYzNox8kMGl8hjo2kiI/k7rqvyEbDIl/eCWhg4U5kCYB6qwF23fMHEYObubakaJuXQLZt9Kglx+jBCPd7sbK6nGNwkhNlbX1v/F+XruEvZMFGZeqq4pJGTHfdyBQY06gVjBp+/IHw1SbryHCaoqY4fn4GRFGWaJwrVXsYpvHYlnJFOub5/AxKFRqCg/OfO463jXTLJdfnMsG/OKA==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: 419.consulting
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: feeba3ea-7be8-4bbc-16e0-08dbffb63a2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2023 10:43:52.7675 (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: 8M/1uSNcmmR5nKKdZAv2nkLvmuXIhnWL3EkAivNOa3tTGA8foWjgSfvPRWPf02rw4oMBAXvcMDQ6Gwg2K9NRFHjzrN6Z5/yHEKWWVmRP8AY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB5133
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/lgJE5I5nWOVdp-TilleU7fGoXKQ>
Subject: Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 18 Dec 2023 10:44:00 -0000

> At 03:12 AM 18-12-2023, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Andrew, are you arguing for anything in existing or future protocols which would permit third party intercept?

George
To answer your question directly, given that the IAB document acknowledges the societal harms caused by, or magnified by, the Internet, I would like to know whether it intends to produce a further statement or document that addresses that issue.  That is what prompted by earlier post on this topic to the list.  

You highlight the potential trade-offs between individual privacy and law enforcement [we should probably note that privacy is a qualified rather than absolute right in many (most?) jurisdictions].  The IAB's "Management Techniques in Encrypted Networks" (M-TEN) workshop considered some of the issues posed by encryption for network management purposes.  In particular, I note that the Red Rover position paper [1] considered the potential for privacy-preserving content filtering as did the one on zero knowledge middleboxes [2].  


Reflecting further on the IAB statement, I do believe that the lack of inclusion of a clear definition of client-side scanning within the IAB's statement is problematic.  I suspect that the real issue relates to the results of that scanning being shared with a third party without the knowledge of the user rather than the scanning per se.  If that is the case, this principle has already been largely addressed by RFC2084, albeit that document focuses on wiretapping rather than on-device scanning.  It should be quite simple for an update of the RFC to address this issue too.

If however the IAB is against the concept of client-side scanning itself, rather than just the reporting of the results of that scanning to a third party without the knowledge of the user, then this needs a proper explanation.  It would be a surprising position for the IAB to take of course as it would essentially suggest that it is against, for example, the detection of malware.  Hence an updated statement would be beneficial that includes a definition of client-side scanning and clarity on the specific aspect(s) of that practice that are objectionable to the IAB.


More generally, I hope that sufficient time will be allocated during the IETF 119 meeting for a discussion about this statement and the various technical, policy and societal issues that it raises, ideally beyond what would be possible as one of several slots within the regular IAB Open meeting.   


Andrew


[1] https://www.ietf.org/ietf-ftp/slides/slides-mtenws-paper-red-rover-a-collaborative-approach-to-content-filtering-pauly-barnes-00.pdf 

[2] https://www.ietf.org/archive/id/draft-iab-m-ten-workshop-00.html#GRUBBS 


-----Original Message-----
From: George Michaelson <ggm@algebras.org> 
Sent: Monday, December 18, 2023 3:12 AM
To: Andrew Campling <andrew.campling@419.consulting>
Cc: iab@iab.org; architecture-discuss@ietf.org; S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content

Andrew, are you arguing for anything in existing or future protocols which would permit third party intercept? Because at the core, thats the only modification which can address what I believe you are concerned about, in this context: if end to end encryption coupled with source and destination masking combines to make it infeasible to understand what is said between two parties or who they really are, there is no forseeable mechanism in protocols which is going to protect against knowing parties using these protocols to conduct illegal activity.

I think it becomes political to suggest we should of our own volition, design systems which address the problem when our primary drive for other reasons has been to design systems which deliberately create the problem. You're arguing for a reversal of intent, if I read this right. There is nothing wrong in advocating for this. But, I think it should be overt, not implicit. I believe you advocate for a significant change in both posture and technology at large. If I am remembering correctly you are based in the UK and argue from a British perspective with British laws which are now on the book in the UK, similar ones emerging in the EU, and probably coming to Australia shortly. So, there clearly is a wider political agenda to legislate in this space.

This is not for one minute to suggest there is no problem, or that it shouldn't be addressed. The concern here, is that to me it appears infeasible to design systems which do what you want, and still do what everyone else wants in their normal daily discourses and use of the
internet: You can't be both (anonymous and private) and (subject to review of your content and who you communicate with) at the same time.
In effect, either the act of using encryption has to be contextually criminalised, or we have to accept limits to how private we can be, all the time.

Do you have any specific concrete suggestion of a privacy and anonymity preserving design of systems, which is going to permit the authorities to confirm no criminal activity is taking place? Because nobody else does, that I can see. And most non-protocol changes would be fundamental changes in law, such as a removal of a presumption of innocence if parties refuse to decode communications which are frankly, extremely concerning. Bear in mind that the IETF legally is incorporated in one political economy but as participants we span many. There are differing views of the laws, primacy of one law over another law, rights and responsibilities.
Which means you are in effect beginning to argue for an end to the right (wrong word, used loosely) to privacy, and anonymity. If I am wrong, please can you explain what it is you seek?

Because of how I wrote previously I want to be clear I am not seeking to objectify you, or paint you "wrong" on this. I am trying to understand what specifically you think is going to happen. And if I say "you are concerned about" I do not mean to imply nobody else is concerned, or there is no concern here, or that doing nothing has no consequences.

Abhorrent crimes of all kinds are being committed. These crimes also use the roads, electricity supply, water, sewage, the legal system at large, digital cameras, lots of infrastructure devices and utility functions are brought to bear indirectly in the commisioning of crimes. The unique property we have in this, is that we designed systems which include methods of masking identity and content, where the others are simply volts, or pressure, or things on devices which can be siezed and examined under warrant. In the case of encrypted communications, you can't do that, and still have the value inherent in their encryption. At least, thats how I understand it.

cheers

-George

On Mon, Dec 18, 2023 at 10:45 AM Andrew Campling <andrew.campling@419.consulting> wrote:
>
> At 8:08 PM 16-12-2023, S Moonesamy <sm+ietf@elandsys.com> wrote:
>
> > I would like to commend the members of the IAB for acknowledging the concern about societal harms.
>
> The document states that "The IAB shares concerns about societal harms through the distribution of illegal content and criminal action on the Internet and recognizes the need to protect Internet users from such threats".  Whilst the document rules out the use of client-side scanning (a definition of which could usefully be added), it does not go on to indicate how the IAB recommends Internet users should be protected from such threats; is there a plan to produce a separate document that addresses this important issue?
>
>
> Andrew
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss