Re: Approaching the IETF - A View from Civil Society

John Curran <jcurran@istaff.org> Thu, 03 August 2023 02:03 UTC

Return-Path: <jcurran@istaff.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D91C151990 for <ietf@ietfa.amsl.com>; Wed, 2 Aug 2023 19:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.804
X-Spam-Level:
X-Spam-Status: No, score=-2.804 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=istaff.org
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 duglAiyWpNOC for <ietf@ietfa.amsl.com>; Wed, 2 Aug 2023 19:03:48 -0700 (PDT)
Received: from qs51p00im-qukt01072502.me.com (qs51p00im-qukt01072502.me.com [17.57.155.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07929C1516F2 for <ietf@ietf.org>; Wed, 2 Aug 2023 19:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=istaff.org; s=sig1; t=1691028227; bh=nO4swcFzIZWix3/MDAd3qBsu99vsWBx1VekRYMrpS8Y=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=nodNCxg1KxRrA3N1UyRKINYOweo8ROLRLwt6Yny3sFLJbCcvGHSEocX5U+NmJwmb6 hMGtkTY5ArfbRmOm/WxIEkk86+9D1WLAfCoo2qQqA1UGiIpNdjhdl1IzBYOzruFvcM xuGoZPgrEqLguLeJqO5IwC+yBzP3Kf5CrkSUonkr/f2kkkJthD4J/eIAuIxe+SxPiT 3XW6XTcmJ/ZYsKnym50qL5UM+qz9uDrTNkqfZFUoZxclCvAD2Z5rXeWiMV7lctZ6Qq 0RWC/A2AIah92K1EpWkq+PN1Bdc6EH1BxXlKzjdz+iv4gAM1ErSeUeXoGJgrv2M5QG Hd5jRzlNIzBjQ==
Received: from smtpclient.apple (qs51p00im-dlb-asmtp-mailmevip.me.com [17.57.155.28]) by qs51p00im-qukt01072502.me.com (Postfix) with ESMTPSA id E8F686EC0181; Thu, 3 Aug 2023 02:03:45 +0000 (UTC)
From: John Curran <jcurran@istaff.org>
Message-Id: <D5B0FCB1-078E-4410-BDE6-50AB52A4DD7F@istaff.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01E157ED-17F3-4450-8104-9B1FD7B024F8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: Approaching the IETF - A View from Civil Society
Date: Wed, 02 Aug 2023 22:03:34 -0400
In-Reply-To: <784237fb-d190-90e7-abe4-c80e442f2379@huitema.net>
Cc: John Levine <johnl@taugh.com>, ietf@ietf.org, moore@network-heretics.com
To: Christian Huitema <huitema@huitema.net>
References: <20230802235348.37ED6FF611C0@ary.local> <784237fb-d190-90e7-abe4-c80e442f2379@huitema.net>
X-Mailer: Apple Mail (2.3731.600.7)
X-Proofpoint-GUID: xUp_987qeY2opozQtmpfqM8UqljVtRjd
X-Proofpoint-ORIG-GUID: xUp_987qeY2opozQtmpfqM8UqljVtRjd
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.1.170-22c6f66c430a71ce266a39bfe25bc2903e8d5c8f:6.0.425,18.0.572,17.0.605.474.0000000 definitions=2022-01-11_01:2022-01-11_01,2020-02-14_11,2020-01-23_02 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 clxscore=1030 spamscore=0 bulkscore=0 mlxlogscore=693 phishscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2308030017
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5rVtHamcrtl44J2dor9PRwNQ7SY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2023 02:03:52 -0000

> On Aug 2, 2023, at 8:52 PM, Christian Huitema <huitema@huitema.net> wrote:
> On 8/2/2023 4:53 PM, John Levine wrote:
>> It appears that Keith Moore  <moore@network-heretics.com> said
>>> Everyone needs to understand that a likely effect of any CSAM
>>> countermeasure is to increase the distribution and production of CSAM,
>>> and with it the number of victims.
>> Um, what?
> 
> That's the general tit-for-tat between offense and defense. We have seen it with spam: better spam detection begets smarter hiding of spam, and vice versa. The same is very likely to happen with CSAM. If a CSAM scanning technology is applied at control points, the criminals who profit from distributing this material would probably find some way to tweak their materials and evade that particular technology, which will evolve, etc. It will not stop if only a fraction of the criminals and their audience are caught, because there will always remain a substantial fraction in the wild to evolve their methods.

Christian - 

On the surface, it would appear that particular argument (countermeasures have to be highly effective or else they simply encourage evolution and thus become ineffective over time) could be applied equally well to a large range of security measures – including many that are widely deployed today such as home and automobile locks, network intrusion monitoring, passwords on computer accounts, etc.   Somehow we’ve determined that these measures remain useful, despite their imperfect nature and the continuous state of attack/defense evolution. 

Now one can argue that real world security analogies don’t apply, because in the real world there is often the prosecution of culprits – unlike occurs with those caught in spam filters – but I would note that there is rather significant prosecution efforts (and successes) today against CSAM production and distribution, so that comparison to spam detection really doesn’t hold up – even modestly functional measures that mitigate a small additional fraction of the activity would make a real very difference to those who don’t have to suffer the harms of trafficking & production. 

Perhaps I misunderstood, and there’s a more coherent formulation of why countermeasures are likely to "to increase the distribution and production of CSAM and with it the number of victims” – if so, can you elaborate?

Thanks,
/John

p.s. disclaimers(s):  my views alone. shock hazard – no user serviceable parts inside.