From nobody Fri Apr 10 16:18:58 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEF3A10EC for ; Fri, 10 Apr 2020 16:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=IA7U3RMa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bL5kjrxZ 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 pcO170mA59mg for ; Fri, 10 Apr 2020 16:18:55 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2DC3A10EA for ; Fri, 10 Apr 2020 16:18:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 078D54B4; Fri, 10 Apr 2020 19:18:53 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 10 Apr 2020 19:18:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=fPLBHzipsendATYg4Jz6QHvDRjINlXW cfDdt8FBOxpU=; b=IA7U3RMaAs4jkvyMmQSzXyvK9SzMR+Ps1QrR9TCB4jpu00m SCgm09uhBW8B3ri1vtqI/gdUZi2br+R5DnjeDVfYKVDyCj01xhL6DHipZ0AnyBT0 +klb1UDsfveI7GtB2G9g7o/oduI3bO9inIPMfGHOEbrOJp12VG+eaKe//gbncwWq oWAafcZESG/xehcMiFUezhLuWZXuMxXBHljWh7ec5HA8FsnOMBF7X23zqwb6I6Xc 9kYW4mJZnufYUp+ganuDSbFD6o3yY0zPtqdMSYr01nBBz19hdCRFSymf50GhAb8r avFe2wXsQklW2aT725f/wJpTDHCxzlYqOyPhiOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=fPLBHz ipsendATYg4Jz6QHvDRjINlXWcfDdt8FBOxpU=; b=bL5kjrxZSL4x+BqKmdg5Xc uWxJ7vLcKDuTw5qnYGPPBU8HoXaMHg5P9MgDoD/io7ucL+MDyfxozBC4v36hbbT7 Km7H25wiiBq763sgeh3n6to+vnsnkEe3N5RybiY82pLAsSm1hTDcUuLZmTFL39k2 iEHX6cTkDG40+oAo96FLnX7nigka4Tme3Rz0qbqnR65vT3PQlAvVumidV2v/TSJ5 agLHJ2134+wX2D/20lc9NFsaDjrEkScneANAIl8T+xC5yNxHHossZiQi2hshZqPo eqMo/3Dc1Muy+ssTTpCJH06sapIF2CIoorjrzJ2jvEXiZbpm+Q30PsXcsqjW0BFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdefgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinh hgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 277103C00A1; Fri, 10 Apr 2020 19:18:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: <53dba784-ff22-4715-aed3-b629a56b8a07@www.fastmail.com> In-Reply-To: References: <819285e9-f34e-4815-a046-852c453d23f8@www.fastmail.com> Date: Fri, 10 Apr 2020 16:18:32 -0700 From: "Christopher Wood" To: "Fernando Gont" , pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] Review of draft-irtf-pearg-numeric-ids-history-01 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 23:18:57 -0000 On Sun, Mar 29, 2020, at 5:49 PM, Fernando Gont wrote: > Hello, Chris, > > Thanks a lot for your feedback! In-line! > > On 28/3/20 21:44, Christopher Wood wrote: > > Document: draft-irtf-pearg-numeric-ids-history-01 [https://tools.ietf.org/id/draft-irtf-pearg-numeric-ids-history-01.txt] > > > > Assessment: Almost ready > > > > Thanks for putting this information together! I think the analysis and timeline are > > a testament to the importance and subtleties of numeric identifier generation. > > The amount of detail is quite comprehensive. Even if there are glaring omissions, > > I think the overall point is made clear. > > I'm curious about the omissions... which ones? If only for the sake of > curiousity. :-) (FWIW, for the most part we documented numeric IDs from > different layers that we were closely involved in... not that there are > not other, though!) Sorry, I meant that I don't know what's omitted, if anything! > > I only have some high level comments on the document, along with several nits. > > (If it'd be easier, and if you have the repository on GitHub, I can submit a PR > > for the nits.) > > Here it is: https://github.com/fgont/numeric-ids . The working copy of > the I-Ds are the ones with the "-latest" suffix. > > > > > > > Comments: > > > > - Section 2: Neither hard nor soft failures are used in the document. Can we just remove > > these terms altogether? > > Definitely yes. Done! > > > > - Section 3: Perhaps it's worth mentioning that we consider the standard Dolev-Yao > > style attacker as outlined in RFC3552? > > Does RFC3552 actually mention it? > > > > - Section 5, second paragraph: It looks the start of this sentence (or paragraph) > > was accidentally deleted: > > > > he interoperability requirements for TCP ISNs are probably not > > clearly spelled out as one would expect. > > s/he/The/ -- done, thanks! > > > > > > Nits: > > [...] > I have not applied these yet. If you want, you can send pull requests. > Otherwise I will incorporate these comments tomorrow. I assume you've done this since tomorrow has come and gone. Please let me know if that's not the case, and I can try to make time for it. (Otherwise, I'll leave it to your judgement to make changes.) > Thanks a lot! My pleasure! Best, Chris From nobody Fri Apr 10 19:48:47 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189DB3A15D0 for ; Fri, 10 Apr 2020 19:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=glG1rjfq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1XD2Y1ks 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 2Ui8kY6nxJ1S for ; Fri, 10 Apr 2020 19:48:43 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A813A15CE for ; Fri, 10 Apr 2020 19:48:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3A97B487 for ; Fri, 10 Apr 2020 22:48:43 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 10 Apr 2020 22:48:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=L+CAwZE4qYe4Qpm6JjMwUCKN46K7s7yQDQ+BkpZJOas=; b=glG1rjfq +8J+rRX6AVwNIh5cVlMs8T4VKDHZDvZ5tHqC37MLoVGXzxnrjLYL5lCTVpUqlIFx /Q/aEOpFQxpvZqhCbSNATOoMQvhoiCIV8H/GfwK4YuYfSULOvtXgKeDobty2AIiW NWBBeQJBMzEhtCKhgLHO3eHvNYSEimHjJYKeGZm/lRu8umwhZVjT5TvnVSk6eCDL GDpmjmekIWzyc3i62xY+iUk0zrv4hQ8JTsFO/hRmU1MG2mdEmQg9e8HUWFZ/hgox crkhDRmVjsIijCLopMQfVLvc/UvKIz9UatbZ1HQvWrcDb0Ep3gyX485RXbdJGvGn IB0i84Q+5/6lhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=L+CAwZE4qYe4Qpm6JjMwUCKN46K7s 7yQDQ+BkpZJOas=; b=1XD2Y1ksztYc+58RomPCl91cvyP4oGZY0YYCzpzV2uQiR kwbrqlLpN8g1nYDKx9CuwtQK36fyoxrxk0thgEjYL5ujjtSJOv7B8unOfvpQYgda Cyh1jZJ1e7b6oSCFvDlIo21mEWovwzA3MJeX5WI7fV6voJR8ygYd5yh8Ec6if3Hc stB0c6SIzK0YW5b3zbM3xQoQJa4GLUsNAE+NGqZRkYITwHOz2vh9ubmEOxeNPT1j RJHjWYr9JSVlNQmjnLFa+ggUAU81mlIWfilwqaI0e4hwWvffiyBxgcqBINIM5Tlh rNbyh4dVATKR2tnZ0Np+VW16aOnDgFhwO44BMrWCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdefgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhith hhuhgsrdgtohhmpdhushgvnhhigidrohhrghdpihhrthhfrdhorhhgpdhumhgurdgvughu necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfi eshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 55D153C00A1; Fri, 10 Apr 2020 22:48:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: Date: Fri, 10 Apr 2020 19:48:22 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 02:48:46 -0000 Document: draft-irtf-pearg-censorship-02 [https://tools.ietf.org/html/draft-irtf-pearg-censorship-02] Assessment: Almost ready Thanks for your work on this document! It has a lot of very useful information. I think it's nearly ready to go with some cleanup and additional references. Below is my review of its contents (with no hat on). I prepared an editorial PR --- aiming towards format consistency -- against the draft repository [0]. I hope it's useful! Comments: - Section 3.2.1: This section describes common ways in which censors use HTTP fields for filtering with a pile of references at the bottom. Upon first read, it seemed to lack relevant citations. (For example, the sentence As such, "method" and "host" are the two fields used most often for ubiquitous censorship. seemed like it could stand to use a reference. However, this seems to be covered by one of the empirical examples at the end of this section. Perhaps Section 3.2 could note this structure for each of its subsections? Perhaps: "The following subsections describe properties and tradeoffs of common ways in which censors filter using application-layer information. Each subsection includes empirical examples describing these common behaviors for further reference." - Section 3.2.4.1. should probably reference draft-ietf-tls-sni-encryption or draft-ietf-tls-esni. (I'm happy to help word-smith that text, if you want or need assistance!) Also, the bit about fallback to SSL (pre TLS 1.0) seems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, for example. I might remove this bit. I might also include a reference to [1] as further SNI-based blocking reading. - Section 3.3.1: Assuming that IP address filtering is efficient, it might be worth citing [2] given that it studies the (often unique) relationship between address and domain. It might also be worth mentioning DoH(443) and noting the challenges it raises for blocking parties. - Section 3.3.2: Is it worth mentioning Pluggable Transports here, especially in the context of blocking Tor? - Section 3.3: I was surprised to see no mention of QUIC in this section. Perhaps we could replace "TCP/IP header" references with "transport header references"? The information about network addresses and ports equally applies to TCP and QUIC, and including both seems prudent so as to not give the wrong impression about what QUIC exposes (or doesn't). - Section 4.4.1: There's no mention of encrypted DNS here. While it's true that "DNS lying" and other examples are not completely mitigated with stub-to-resolver encryption, it does change the threat model slightly. Maybe DoH/DoT are worth including? It might also be worth noting limited client support for DNSSEC, perhaps after this sentence: "Additionally, the above mechanisms rely on DNSSEC not being deployed or DNSSEC validation not being active on the client or recursive resolver." - Section 4.2.2: Is packet dropping not a form of filtering? I was surprised to see it in the interference section. - Section 4.2.3: It's probably worth mentioning QUIC here, especially as it complicates this type of attack. It might also be worth citing recent research [3] on off-path TCP attacks, noting that the censor need not be on-path to interfere with service. - I was surprised to see this recent SoK paper [4] missing from the references. It has a lot of additional information, particularly in Tables V and VI, about different types of filtration mechanisms and how they impact users (by under or over blocking). That said, integrating this paper will be a chore. So, given that the landscape of relevant research and empirical evidence will undoubtedly continue changing, perhaps we can simply drop a reference somewhere? Nits: - Section 2: SmartFilter is missing a reference. - Section 3.1: "Internet Service Providers have until now been the most frequently exploited point of control" probably also warrants a reference, if possible. - Section 3.2.1: The [Verkamp-2012] reference seems broken. [0] https://github.com/josephlhall/rfc-censorship-tech/pull/53 [1] https://www.usenix.org/system/files/foci19-paper_chai_update.pdf [2] https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf [3] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf [4] http://www.cs.umd.edu/class/fall2018/cmsc818O/papers/sok-censorship.pdf Best, Chris From nobody Sat Apr 11 15:36:49 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960613A1A34 for ; Sat, 11 Apr 2020 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 263YwHxWjZuI for ; Sat, 11 Apr 2020 15:36:45 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2059.outbound.protection.outlook.com [40.107.94.59]) (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 502D03A1A32 for ; Sat, 11 Apr 2020 15:36:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gP/waG3yFgAh5rW7WsWlHBDIQnA3A9biIYmC5ZUAHcLdrG4L4sxgz0R7318DwhJzGTMdeTajooDQGjkGaxaNxvNubZiIy9nI2hexKZZmsou4fxIlxTSNPZ9uVMXe11C0sqIR70TruNm3+Sgu1Rc57OKHqgKYtWhgJkNzxrHL84quqgQ0WwQ+q2Y+Evhnx44OdIWM8zYEvTyuK7quiVJoXkoYxEtOEU9Il5JgKcy0DVtJrJJL7Mn+7kmhNXbUB4BFRJhbVwGOTRVBcbgTL1dxROyPPQgLsGhEGu1sMbhzu8WzqScQPneXMr2whMb0p/ES4s3IXZbkpfMkErQgWotzCg== 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=3LetqFua8OmRP20OgIThNIgE4mGAUAQY303u2ePleMY=; b=XraNdRcMO5sB4XssJqeLxF7vImcB52TYf2JGXbL9ifk575ckZPQLvvthTWzC4p/82IrTdnk1Y7cmG+jFQrLj+Tbtoj+3fdmCDpiGZ+NIGlSXJYhMb+FUEWuplNFrh4Mz++VD1qDqaoOa7ltSVRrWTMHRotc1Xwjie6xgp20+zJSzUkKGIv/l1+y4vo6MHIesRjI6firNevmgVNfZNf7Allt+uxTAEzODfKJxOlDZFcSMpXroj8TiXK6yee/Ha0Y++cqo8lR+wNAIbQG8hlweVm+Kz8mwGUe4qQm9jET9+8NQLMMUEUbdiGYCQwJq+TeM+D2OdPmO3v/+t8rhIBFrxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LetqFua8OmRP20OgIThNIgE4mGAUAQY303u2ePleMY=; b=GT/QkX/nEMJ1fCZ0+WCQpzKNrBJdv03lxlZH4O7MmaVcT9WMKmZDbyy452Lop05HQbUcqGPdK6p1p/B/GgB9gau+xTpePp59ZlW5KbN8PvDjyPareYXD3idl2HuyWs+32v6hGO/DDVHsG7A1NfwS0m99tiMghyEIjC645Ha7pD8= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6708.namprd06.prod.outlook.com (2603:10b6:a03:232::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Sat, 11 Apr 2020 22:36:37 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::3891:1ca6:1667:cbd]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::3891:1ca6:1667:cbd%2]) with mapi id 15.20.2900.026; Sat, 11 Apr 2020 22:36:37 +0000 From: Joseph Lorenzo Hall To: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] draft-irtf-pearg-censorship review Thread-Index: AQHWD6u84dP2BqvmUU+akQqO5soH/ah0g21j Date: Sat, 11 Apr 2020 22:36:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hall@isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc7a3c65-ff14-4d9e-0aee-08d7de68cc0f x-ms-traffictypediagnostic: BY5PR06MB6708: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 03706074BC x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(376002)(396003)(39840400004)(346002)(366004)(136003)(66446008)(64756008)(5660300002)(9686003)(316002)(66556008)(53546011)(8936002)(81156014)(66476007)(66946007)(76116006)(55016002)(8676002)(86362001)(110136005)(2906002)(91956017)(186003)(6506007)(52536014)(33656002)(66574012)(26005)(966005)(7696005)(71200400001)(478600001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ey7Hmqggns4tmK8sghzb8rI5Pb9bsNsFwx1w8IuOAh8rB7vjV7iSzGvUINSHYQRKQf3PJ7rspeOpYxSo737ULOt0zZOzSkBoxvfzmTqV1q3aEtR0S2T/iI0EcN/ZFoJTig9c25h3HpCCxoL2dpGfGk0cRYXSzWDazoBVLmdPmQM4XHPePvX75bHmc6J9wW9LZXyIyelbgluKljqp+rW1JloGPGwAoK1WCkzheUFw4CBgzDG/jo7lNihLi3Pe6BbfUHcxEPwl9YHdIZoBp1k0qbZrVZM0qaJxXWkGEarRfQyqWMKaug1R5KaYOFbweAoN3z2PEjNcByHoL5FuTotP7Y/Ige0EWe7ltYBLJsL5/oCUKS3ikUotR0Pvh0gls9aXLf0RmJ0xgpnXvh6RzT3EI5KHWLUraRAxI6ZJ4jibopOSB6VKKSD3qDZdXnHwVzVghdQwOkxK52RUEZV8Wnd288xSYoOPAWNV0hn0vrafKRBSL9LBB3lQkb7cr9gIM/vG0XMgoO4ErkfIzgGm8CJyAg== x-ms-exchange-antispam-messagedata: rit2HsFPztYe+Wa+ODwm2Z9Gs235gjMsf5xP8BpfOgl6keVEGyMYNeBV+qSf+iHtwlbxXge63Z4tJNBCTFReOGp5kz4JjUjmC5nwtlFxHNu6yhrASsrboNXNr5LqD1DjT8ZVaV2CiieR+JpOd9ebxw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451A6AE5AC2E65983DD8433B1DF0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: bc7a3c65-ff14-4d9e-0aee-08d7de68cc0f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2020 22:36:37.6433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EuKaZdq3U29hQbBJzagUCjDzS/Lc6RQI3DQyM7ZkI/WgYbsXZwZ6KfsZsQ76OY1M X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6708 Archived-At: Subject: Re: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 22:36:48 -0000 --_000_BY5PR06MB6451A6AE5AC2E65983DD8433B1DF0BY5PR06MB6451namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, Chris! Very helpful, and clearly it is in need of some key updat= es over the six years or so in the drafting. I'll make the changes I can an= y merge your editorial PR tomorrow; I'll be sure to come back with any ques= tions. Cheers, Joe -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 ________________________________ From: Pearg on behalf of Christopher Wood Sent: Friday, April 10, 2020 10:48:22 PM To: pearg@irtf.org Subject: [Pearg] draft-irtf-pearg-censorship review Document: draft-irtf-pearg-censorship-02 [https://tools.ietf.org/html/draft= -irtf-pearg-censorship-02] Assessment: Almost ready Thanks for your work on this document! It has a lot of very useful informat= ion. I think it's nearly ready to go with some cleanup and additional refer= ences. Below is my review of its contents (with no hat on). I prepared an editoria= l PR --- aiming towards format consistency -- against the draft repository = [0]. I hope it's useful! Comments: - Section 3.2.1: This section describes common ways in which censors use HT= TP fields for filtering with a pile of references at the bottom. Upon first= read, it seemed to lack relevant citations. (For example, the sentence As such, "method" and "host" are the two fields used most often for ubiq= uitous censorship. seemed like it could stand to use a reference. However, this seems to be co= vered by one of the empirical examples at the end of this section. Perhaps = Section 3.2 could note this structure for each of its subsections? Perhaps: "The following subsections describe properties and tradeoffs of common w= ays in which censors filter using application-layer information. Each subse= ction includes empirical examples describing these common behaviors for fur= ther reference." - Section 3.2.4.1. should probably reference draft-ietf-tls-sni-encryption = or draft-ietf-tls-esni. (I'm happy to help word-smith that text, if you wan= t or need assistance!) Also, the bit about fallback to SSL (pre TLS 1.0) se= ems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, for e= xample. I might remove this bit. I might also include a reference to [1] as= further SNI-based blocking reading. - Section 3.3.1: Assuming that IP address filtering is efficient, it might = be worth citing [2] given that it studies the (often unique) relationship b= etween address and domain. It might also be worth mentioning DoH(443) and n= oting the challenges it raises for blocking parties. - Section 3.3.2: Is it worth mentioning Pluggable Transports here, especial= ly in the context of blocking Tor? - Section 3.3: I was surprised to see no mention of QUIC in this section. P= erhaps we could replace "TCP/IP header" references with "transport header r= eferences"? The information about network addresses and ports equally appli= es to TCP and QUIC, and including both seems prudent so as to not give the = wrong impression about what QUIC exposes (or doesn't). - Section 4.4.1: There's no mention of encrypted DNS here. While it's true = that "DNS lying" and other examples are not completely mitigated with stub-= to-resolver encryption, it does change the threat model slightly. Maybe DoH= /DoT are worth including? It might also be worth noting limited client supp= ort for DNSSEC, perhaps after this sentence: "Additionally, the above mechanisms rely on DNSSEC not being deployed or= DNSSEC validation not being active on the client or recursive resolver." - Section 4.2.2: Is packet dropping not a form of filtering? I was surprise= d to see it in the interference section. - Section 4.2.3: It's probably worth mentioning QUIC here, especially as it= complicates this type of attack. It might also be worth citing recent rese= arch [3] on off-path TCP attacks, noting that the censor need not be on-pat= h to interfere with service. - I was surprised to see this recent SoK paper [4] missing from the referen= ces. It has a lot of additional information, particularly in Tables V and V= I, about different types of filtration mechanisms and how they impact users= (by under or over blocking). That said, integrating this paper will be a c= hore. So, given that the landscape of relevant research and empirical evide= nce will undoubtedly continue changing, perhaps we can simply drop a refere= nce somewhere? Nits: - Section 2: SmartFilter is missing a reference. - Section 3.1: "Internet Service Providers have until now been the most fre= quently exploited point of control" probably also warrants a reference, if = possible. - Section 3.2.1: The [Verkamp-2012] reference seems broken. [0] https://github.com/josephlhall/rfc-censorship-tech/pull/53 [1] https://www.usenix.org/system/files/foci19-paper_chai_update.pdf [2] https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf [3] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_p= aper_cao.pdf [4] http://www.cs.umd.edu/class/fall2018/cmsc818O/papers/sok-censorship.pdf Best, Chris -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg --_000_BY5PR06MB6451A6AE5AC2E65983DD8433B1DF0BY5PR06MB6451namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you, Chris! Very helpful, and clearly = it is in need of some key updates over the six years or so in the drafting.= I'll make the changes I can any merge your editorial PR tomorrow; I'll be = sure to come back with any questions. Cheers, Joe

--
Joseph Lorenzo Hall, Senior Vice President, = Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
From: Pearg <pearg-bounc= es@irtf.org> on behalf of Christopher Wood <caw@heapingbits.net> Sent: Friday, April 10, 2020 10:48:22 PM
To: pearg@irtf.org <pearg@irtf.org>
Subject: [Pearg] draft-irtf-pearg-censorship review
 
Document: draft-irtf-pearg-censorship-02 [https://too= ls.ietf.org/html/draft-irtf-pearg-censorship-02]

Assessment: Almost ready

Thanks for your work on this document! It has a lot of very useful informat= ion. I think it's nearly ready to go with some cleanup and additional refer= ences.

Below is my review of its contents (with no hat on). I prepared an editoria= l PR --- aiming towards format consistency -- against the draft repository = [0]. I hope it's useful!

Comments:

- Section 3.2.1: This section describes common ways in which censors use HT= TP fields for filtering with a pile of references at the bottom. Upon first= read, it seemed to lack relevant citations. (For example, the sentence

   As such, "method" and "host" are the two f= ields used most often for ubiquitous censorship.

seemed like it could stand to use a reference. However, this seems to be co= vered by one of the empirical examples at the end of this section. Perhaps = Section 3.2 could note this structure for each of its subsections? Perhaps:=

   "The following subsections describe properties and tradeo= ffs of common ways in which censors filter using application-layer informat= ion. Each subsection includes empirical examples describing these common be= haviors for further reference."

- Section 3.2.4.1. should probably reference draft-ietf-tls-sni-encryption = or draft-ietf-tls-esni. (I'm happy to help word-smith that text, if you wan= t or need assistance!) Also, the bit about fallback to SSL (pre TLS 1.0) se= ems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, for example. I might remove this bit. I = might also include a reference to [1] as further SNI-based blocking reading= .
- Section 3.3.1: Assuming that IP address filtering is efficient, it might = be worth citing [2] given that it studies the (often unique) relationship b= etween address and domain. It might also be worth mentioning DoH(443) and n= oting the challenges it raises for blocking parties.
- Section 3.3.2: Is it worth mentioning Pluggable Transports here, especial= ly in the context of blocking Tor?
- Section 3.3: I was surprised to see no mention of QUIC in this section. P= erhaps we could replace "TCP/IP header" references with "tra= nsport header references"? The information about network addresses and= ports equally applies to TCP and QUIC, and including both seems prudent so as to not give the wrong impression about what QUIC = exposes (or doesn't).
- Section 4.4.1: There's no mention of encrypted DNS here. While it's true = that "DNS lying" and other examples are not completely mitigated = with stub-to-resolver encryption, it does change the threat model slightly.= Maybe DoH/DoT are worth including? It might also be worth noting limited client support for DNSSEC, perhaps after this= sentence:

   "Additionally, the above mechanisms rely on DNSSEC not be= ing deployed or DNSSEC validation not being active on the client or recursi= ve resolver."

- Section 4.2.2: Is packet dropping not a form of filtering? I was surprise= d to see it in the interference section.
- Section 4.2.3: It's probably worth mentioning QUIC here, especially as it= complicates this type of attack. It might also be worth citing recent rese= arch [3] on off-path TCP attacks, noting that the censor need not be on-pat= h to interfere with service.
- I was surprised to see this recent SoK paper [4] missing from the referen= ces. It has a lot of additional information, particularly in Tables V and V= I, about different types of filtration mechanisms and how they impact users= (by under or over blocking). That said, integrating this paper will be a chore. So, given that the landscape= of relevant research and empirical evidence will undoubtedly continue chan= ging, perhaps we can simply drop a reference somewhere?

Nits:

- Section 2: SmartFilter is missing a reference.
- Section 3.1: "Internet Service Providers have until now been the mos= t frequently exploited point of control" probably also warrants a refe= rence, if possible.
- Section 3.2.1: The [Verkamp-2012] reference seems broken.

[0] = https://github.com/josephlhall/rfc-censorship-tech/pull/53
[1] https://www.usenix.org/system/files/foci19-paper_chai_update.pdf<= br> [2] https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf
[3] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper= _cao.pdf
[4] http://www.cs.umd.edu/class/fall2018/cmsc818O/papers/sok-censorship.pdf=

Best,
Chris

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.or= g/mailman/listinfo/pearg
--_000_BY5PR06MB6451A6AE5AC2E65983DD8433B1DF0BY5PR06MB6451namp_-- From nobody Sun Apr 12 11:25:47 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5983A2493 for ; Sun, 12 Apr 2020 11:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 nuF1HjRnt-4y for ; Sun, 12 Apr 2020 11:25:40 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2063.outbound.protection.outlook.com [40.107.93.63]) (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 257583A0D8D for ; Sun, 12 Apr 2020 11:25:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YXKvZA+GL53hjM2qeHewdVhcC3eR2f9LsF1rp3UuReZRa6TimTIkpTgc9XqQtrIQWXUBxuUBLtL33wAIqBkqKzkebYMP8nSXg0wi9bpOlsGBzaldWoxxJU2oHKokNQNfYwgBp9r0Jyc23+fRB3+sqN5CgEYWL8iqLzGGr04sCO733hJ4bEiO3MG8GzxexgZIVCpDJ+x8UxTY7lZgB+pj/7/p+J7vvt8NH78378FV/0ubNA2cjTquchrgpH4P6FxAb2sAbE22oQYsJVRocJpirmj3ir+tbx77ObtchXTfDJLPazvACgXMHw3jzkFSt6973aD3kxAkvQrKphpRdSuRqw== 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=bOkqDeVGvm6R8v+Ux0WTwi65CYxwLc1O4lw0ZS+ajK0=; b=HHuB7FtT2Sc/I/IpBzkcRBCQ1jaVHkxqO+0+q5Kpq+RM8ETLsY6JHOJ2A4j7RW336Nu0SoNuRdOPBl1x2ukzj4klcTwjbH2zzbIss8h70JsfoIYDD3dYiOijqr0+CqUqsevNit1tDwj0aIWga3TCp6lz6tdy4dBwysbFYlqDzm9wCILlrAhvN0bfYjJjO+Hk9LM6kK2naYeWmp3h5bREgzL/Zf6Ti6ju6Lj20DdWCpbfRrWSmxiTXiNkFXHTH8guUbUPEBvvmOjddlIT7jnluEbCYfBCfQi9soKxZL8O/+Ada6Kyc/bxg7zDc5v73Q8KdIJIiNDCAnrS/CnenO6ueA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bOkqDeVGvm6R8v+Ux0WTwi65CYxwLc1O4lw0ZS+ajK0=; b=R1vxV1e7pZzY7r7Utth79eEkKUrESzxhKdPwBjqdw9T+RoPiCg0zJy6HptjoZelUDOY1wdZpIE7Xp2EidZGLZMEi0bCpvZFlznwGgGGPDvWTxwfa9YJJllFU3TBwbEtjtqx38udBWc12tch082Ef8Ml8NqOzokHX0FeX7UE49SY= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6593.namprd06.prod.outlook.com (2603:10b6:a03:21e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Sun, 12 Apr 2020 18:25:31 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::3891:1ca6:1667:cbd]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::3891:1ca6:1667:cbd%2]) with mapi id 15.20.2900.026; Sun, 12 Apr 2020 18:25:31 +0000 From: Joseph Lorenzo Hall To: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] draft-irtf-pearg-censorship review Thread-Index: AQHWD6u84dP2BqvmUU+akQqO5soH/ah1z/vm Date: Sun, 12 Apr 2020 18:25:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hall@isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48cedace-5a56-4cb9-6d94-08d7df0ee255 x-ms-traffictypediagnostic: BY5PR06MB6593: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(346002)(136003)(39840400004)(366004)(396003)(376002)(86362001)(15974865002)(52536014)(8676002)(110136005)(8936002)(316002)(55016002)(9686003)(478600001)(19627405001)(81156014)(71200400001)(186003)(66574012)(966005)(2906002)(33656002)(7696005)(66446008)(66556008)(64756008)(66946007)(76116006)(26005)(5660300002)(66476007)(6506007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OmS3zvzXwqSRzfWTIsONp9wUcL8eCbU50e2i4D+WA0anImXwXtwn42vgYPViHujJ4Vl8J7CPRuXH063reeRDCeH7GKQ+Pa/VLX8mN5gVnixZNk64XvsXvqGOyxAQhdVG9CPHPpU630lo2i6gaYrqK97elBJOdRLETq6fqu5JxKH3eafYAj8CA65dHCd9+Nmvv2c+YokoxYHVe1p2brOi6AmeMT7oLk2MmMsUthdI8e70s5JkifD8DRPUSoZFMSR+10rRxqQA/GEF82sEH5glO4wHbksOvPPGUAVKc/JYGJ544UUQAxKP/Mw76QpQOBPWp6thL2YxjuGdcFuI3zjl295hbHVR3Zwh44THIkqgd7Wde8QM+cpyJGvK0qmlTkKe4AczaRNui5o0ShnXJ/+RPKXQr9UgzanU97bYJVlUJOQszCTFZGBb/zd65iUOivx9SYzNkYPgz2LOa0OUDnBbVmeOUWmVF92x88iYujdZ2Tz7+IVao4w25PW+CP31TyGSblJCHyoFVZ822G0lQkSuzA== x-ms-exchange-antispam-messagedata: FbY02jXqcfMBMip+xZ2IFu/6INJWDo95bhd3fAgJxT6y7VGRqtnHnHud+UbI2B+ycWCOmNjeIe/VH4+Xbb3HYkekLNICBg/QmckBBZ/EkAJFEv49GYpannj3xPAd5QrGNeaSNR77+qbszCexGdD0vw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 48cedace-5a56-4cb9-6d94-08d7df0ee255 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2020 18:25:31.3670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p8Y5a3ZVAM1+coHVOFe/8+TSxF8uQ2M6sQluiFqxTh7jdItkUHFBlBFTRX6/P2VC X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6593 Archived-At: Subject: Re: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 18:25:45 -0000 --_000_BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0BY5PR06MB6451namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (also in the github issues) > > Comments: > > > > * Section 3.2.1: This section describes common ways in which censors us= e HTTP fields for filtering with a pile of references at the bottom. Upon f= irst read, it seemed to lack relevant citations. (For example, the sentence > > > As such, "method" and "host" are the two fields used most often for= ubiquitous censorship. > > > > > > seemed like it could stand to use a reference. However, this seems to= be covered by one of the empirical examples at the end of this section. Pe= rhaps Section 3.2 could note this structure for each of its subsections? Pe= rhaps: > > > "The following subsections describe properties and tradeoffs of com= mon ways in which censors filter using application-layer information. Each = subsection includes empirical examples describing these common behaviors fo= r further reference." Looks like you did this in PR #53, thanks! > > * Section 3.2.4.1. should probably reference draft-ietf-tls-sni-encrypt= ion or draft-ietf-tls-esni. (I'm happy to help word-smith that text, if you= want or need assistance!) Also, the bit about fallback to SSL (pre TLS 1.0= ) seems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, f= or example. I might remove this bit. I might also include a reference to [1= ] as further SNI-based blocking reading. Ah, we do cite Chai 2019 a bit later but I will elevate that... and have ju= st made changes to highlight ESNI and remove the SSL fallback bit. > > * Section 3.3.1: Assuming that IP address filtering is efficient, it mi= ght be worth citing [2] given that it studies the (often unique) relationsh= ip between address and domain. It might also be worth mentioning DoH(443) a= nd noting the challenges it raises for blocking parties. Done. > > * Section 3.3.2: Is it worth mentioning Pluggable Transports here, espe= cially in the context of blocking Tor? Done. > > * Section 3.3: I was surprised to see no mention of QUIC in this sectio= n. Perhaps we could replace "TCP/IP header" references with "transport head= er references"? The information about network addresses and ports equally a= pplies to TCP and QUIC, and including both seems prudent so as to not give = the wrong impression about what QUIC exposes (or doesn't). Done. > > * Section 4.4.1: There's no mention of encrypted DNS here. While it's t= rue that "DNS lying" and other examples are not completely mitigated with s= tub-to-resolver encryption, it does change the threat model slightly. Maybe= DoH/DoT are worth including? It might also be worth noting limited client = support for DNSSEC, perhaps after this sentence: > > "Additionally, the above mechanisms rely on DNSSEC not being deployed= or DNSSEC validation not being active on the client or recursive resolver.= " Done. > > * Section 4.2.2: Is packet dropping not a form of filtering? I was surp= rised to see it in the interference section. You may be hung up on the terminology we use where Identification is doing = the technical matching against a set of things one wants to censor and then= Interference is actually performing the technincal action to accomplish th= e censorship or filtering, from the Terminology section: > Prescription is the process by which censors determine what types of mate= rial they should block, i.e., deciding to block a list of pornographic webs= ites. Identification is the process by which censors classify specific traf= fic to be blocked or impaired, i.e., blocking or impairing all webpages con= taining =93sex=94 in the title or traffic to www.sex.example. Interference = is the process by which censors intercede in communication and prevents acc= ess to censored materials by blocking access or impairing the connection. Do we need to make this more clear? > > * Section 4.2.3: It's probably worth mentioning QUIC here, especially a= s it complicates this type of attack. It might also be worth citing recent = research [3] on off-path TCP attacks, noting that the censor need not be on= -path to interfere with service. (That off-path paper is awesome! Had not seen that.) Cool, that makes sense about QUIC. I don't have a good feel for what to wri= te here. How does this feel, "Note, the increasingly popular QUIC protocol = is based on UDP, a connection-less transport protocol, so cannot be attacke= d using TCP RST packet injection." That seems a bit weird... but it sounds like there may be more under the su= rface to your comment so please suggest how that text above could be better= cleaned up? > > * I was surprised to see this recent SoK paper [4] missing from the ref= erences. It has a lot of additional information, particularly in Tables V a= nd VI, about different types of filtration mechanisms and how they impact u= sers (by under or over blocking). That said, integrating this paper will be= a chore. So, given that the landscape of relevant research and empirical e= vidence will undoubtedly continue changing, perhaps we can simply drop a re= ference somewhere? That is a monster, and something I'm looking forward to digging into more. = I'll drop a reference and add an Issue to read and integrate it. > > Nits: > > > > * Section 2: SmartFilter is missing a reference. Done. > > * Section 3.1: "Internet Service Providers have until now been the most= frequently exploited point of control" probably also warrants a reference,= if possible. Changed to "Internet Service Providers are frequently exploited points of c= ontrol." > > * Section 3.2.1: The [Verkamp-2012] reference seems broken. Hmmm, I don't see this. The link works ( https://www.usenix.org/system/file= s/conference/foci12/foci12-final1.pdf ) and the reference is rendering corr= ectly. --_000_BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0BY5PR06MB6451namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
(also in the github issues)

> > Comments:
> >
> > * Section 3.2.1: This section describes common ways in which= censors use HTTP fields for filtering with a pile of references at the bot= tom. Upon first read, it seemed to lack relevant citations. (For example, t= he sentence
> >   > As such, "method" and "host"= are the two fields used most often for ubiquitous censorship.
> >  
> >  
> >   seemed like it could stand to use a reference. Howeve= r, this seems to be covered by one of the empirical examples at the end of = this section. Perhaps Section 3.2 could note this structure for each of its= subsections? Perhaps:
> >   > "The following subsections describe propert= ies and tradeoffs of common ways in which censors filter using application-= layer information. Each subsection includes empirical examples describing t= hese common behaviors for further reference."

Looks like you did this in PR #53, thanks!

> > * Section 3.2.4.1. should probably reference draft-ietf-tls-= sni-encryption or draft-ietf-tls-esni. (I'm happy to help word-smith that t= ext, if you want or need assistance!) Also, the bit about fallback to SSL (= pre TLS 1.0) seems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, for example. I might remove t= his bit. I might also include a reference to [1] as further SNI-based block= ing reading.

Ah, we do cite Chai 2019 a bit later but I will elevate that... and ha= ve just made changes to highlight ESNI and remove the SSL fallback bit.

> > * Section 3.3.1: Assuming that IP address filtering is effic= ient, it might be worth citing [2] given that it studies the (often unique)= relationship between address and domain. It might also be worth mentioning= DoH(443) and noting the challenges it raises for blocking parties.

Done.

> > * Section 3.3.2: Is it worth mentioning Pluggable Transports= here, especially in the context of blocking Tor?

Done.

> > * Section 3.3: I was surprised to see no mention of QUIC in = this section. Perhaps we could replace "TCP/IP header" references= with "transport header references"? The information about networ= k addresses and ports equally applies to TCP and QUIC, and including both seems prudent so as to not give the wrong impression about = what QUIC exposes (or doesn't).

Done.

> > * Section 4.4.1: There's no mention of encrypted DNS here. W= hile it's true that "DNS lying" and other examples are not comple= tely mitigated with stub-to-resolver encryption, it does change the threat = model slightly. Maybe DoH/DoT are worth including? It might also be worth noting limited client support for DNSSEC, perhaps a= fter this sentence:
> >   "Additionally, the above mechanisms rely on DNSS= EC not being deployed or DNSSEC validation not being active on the client o= r recursive resolver."

Done.

> > * Section 4.2.2: Is packet dropping not a form of filtering?= I was surprised to see it in the interference section.

You may be hung up on the terminology we use where Identification is d= oing the technical matching against a set of things one wants to censor and= then Interference is actually performing the technincal action to accompli= sh the censorship or filtering, from the Terminology section:

> Prescription is the process by which censors determine what types= of material they should block, i.e., deciding to block a list of pornograp= hic websites. Identification is the process by which censors classify speci= fic traffic to be blocked or impaired, i.e., blocking or impairing all webpages containing =93sex=94 in the title= or traffic to www.sex.example. Interference is the process by which censor= s intercede in communication and prevents access to censored materials by b= locking access or impairing the connection.

Do we need to make this more clear?

> > * Section 4.2.3: It's probably worth mentioning QUIC here, e= specially as it complicates this type of attack. It might also be worth cit= ing recent research [3] on off-path TCP attacks, noting that the censor nee= d not be on-path to interfere with service.

(That off-path paper is awesome! Had not seen that.)

Cool, that makes sense about QUIC. I don't have a good feel for what t= o write here. How does this feel, "Note, the increasingly popular QUIC= protocol is based on UDP, a connection-less transport protocol, so cannot = be attacked using TCP RST packet injection."

That seems a bit weird... but it sounds like there may be more under t= he surface to your comment so please suggest how that text above could be b= etter cleaned up?

> > * I was surprised to see this recent SoK paper [4] missing f= rom the references. It has a lot of additional information, particularly in= Tables V and VI, about different types of filtration mechanisms and how th= ey impact users (by under or over blocking). That said, integrating this paper will be a chore. So, given that the land= scape of relevant research and empirical evidence will undoubtedly continue= changing, perhaps we can simply drop a reference somewhere?

That is a monster, and something I'm looking forward to digging into m= ore. I'll drop a reference and add an Issue to read and integrate it.

> > Nits:
> >
> > * Section 2: SmartFilter is missing a reference.

Done.

> > * Section 3.1: "Internet Service Providers have until n= ow been the most frequently exploited point of control" probably also = warrants a reference, if possible.

Changed to "Internet Service Providers are frequently exploited p= oints of control."

> > * Section 3.2.1: The [Verkamp-2012] reference seems broken.<= br>

Hmmm, I don't see this. The link works ( https://www.usenix.org/syste= m/files/conference/foci12/foci12-final1.pdf ) and the reference is renderin= g correctly. --_000_BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0BY5PR06MB6451namp_-- From nobody Thu Apr 16 10:39:42 2020 Return-Path: X-Original-To: pearg@irtf.org Delivered-To: pearg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D29B23A08AE; Thu, 16 Apr 2020 10:39:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pearg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pearg@irtf.org Message-ID: <158705877978.28221.25642200238227772@ietfa.amsl.com> Date: Thu, 16 Apr 2020 10:39:39 -0700 Archived-At: Subject: [Pearg] I-D Action: draft-irtf-pearg-numeric-ids-history-02.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:39:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhancements and Assessments Research Group RG of the IRTF. Title : Unfortunate History of Transient Numeric Identifiers Authors : Fernando Gont Ivan Arce Filename : draft-irtf-pearg-numeric-ids-history-02.txt Pages : 25 Date : 2020-04-16 Abstract: This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-history/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-02 https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-history-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-numeric-ids-history-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 16 11:22:32 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3833A0AF1 for ; Thu, 16 Apr 2020 11:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JaewPgAywxlP for ; Thu, 16 Apr 2020 11:22:29 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0951A3A0ADA for ; Thu, 16 Apr 2020 11:22:28 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 94ADF8937C; Thu, 16 Apr 2020 20:22:17 +0200 (CEST) To: Christopher Wood , pearg@irtf.org References: <819285e9-f34e-4815-a046-852c453d23f8@www.fastmail.com> <53dba784-ff22-4715-aed3-b629a56b8a07@www.fastmail.com> From: Fernando Gont Message-ID: Date: Thu, 16 Apr 2020 14:40:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <53dba784-ff22-4715-aed3-b629a56b8a07@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pearg] Review of draft-irtf-pearg-numeric-ids-history-01 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:22:31 -0000 On 10/4/20 20:18, Christopher Wood wrote: [....] >> [...] >> I have not applied these yet. If you want, you can send pull requests. >> Otherwise I will incorporate these comments tomorrow. > > I assume you've done this since tomorrow has come and gone. Please let me know if that's not the case, and I can try to make time for it. (Otherwise, I'll leave it to your judgement to make changes.) > >> Thanks a lot! > > My pleasure! Posted! ;-) (rev -02) Ready to ship? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 22 13:20:53 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235583A0898 for ; Wed, 22 Apr 2020 13:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.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 Zi1w_qK7tmMg for ; Wed, 22 Apr 2020 13:20:49 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99193A0893 for ; Wed, 22 Apr 2020 13:20:49 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id w4so3909251ioc.6 for ; Wed, 22 Apr 2020 13:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=mAfGhaq8BhQEsz8dj2ZX9q/XtPw7HqqNni0+0pbEhEA=; b=ecotjKag6rsC/SXSjKmcLRjQowJKC8L8bUvHRvb09NTxs+k8yJDwOx6vB3naRBNnET vsALq4d30ctjez5Hpg0WxQkAy7s8jfZN06hY0fMOB/BkOQgWFBCO5glX+XC1X9bkVK/0 51ixXDdXYt9w8aePcD7MVhYKMDa4TMgTxr618= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mAfGhaq8BhQEsz8dj2ZX9q/XtPw7HqqNni0+0pbEhEA=; b=oC+QMs4rFYQZSQbnyn24bJB/PtgMy5V9VwQoy7BfJMW65Umi5jgmDQ2eJz8tb9U27z 2x0kStgmpY5qY2T6fXO6rHRlJzhjb6w8J2xs8VSW1HCKrDDAGsHZhM6NHEFbu1T/84FI 9IrjeKDVCugy7PempgVuN6Wfu/XPHTmbXkD4IV6ERRAaxRF4LrZ/Zy2igaroBTDDYtoK q11+2WthIuiENCr9+0lY6T9GXa4tafkHpTgMwQ50ys5iDtTXGu7oecUycwBb35oZmPfm wAAz96ajYMhYGBxxS5m6ugaW8FOBWwjjx4PYyxf4LVptG3vUZyhypdL9NRrprI9eZQIq jA2w== X-Gm-Message-State: AGi0PuaN16jAjGuSslcDK5dMBPJPsnSI9cHaX7QQBsKrdA7fR3lfhl5D A39JO16F/FZEIP1xBWZo5B2Wz9Aff5OuDfPJ6bVDXHWpYVSfJ8WY X-Google-Smtp-Source: APiQypLOrHjhwjqUcwTz9wvQN0TCv7MhvPD9KVxzi8cqQ10o/cPbcojXlu62tIlyS+/HJY5TGy1ckB+TjLys504xSHs= X-Received: by 2002:a05:6638:11d1:: with SMTP id g17mr193556jas.116.1587586848549; Wed, 22 Apr 2020 13:20:48 -0700 (PDT) MIME-Version: 1.0 From: Shivan Sahib Date: Wed, 22 Apr 2020 13:20:37 -0700 Message-ID: To: pearg@irtf.org Content-Type: multipart/alternative; boundary="00000000000028a82205a3e6dea2" Archived-At: Subject: [Pearg] Contact tracing principles I-D X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 20:20:51 -0000 --00000000000028a82205a3e6dea2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Is there interest in having an Internet-Draft around privacy-preserving contact tracing principles? I've been seeing quite a few of them [0][1][2]. Thanks, Shivan [0] ACLU whitepaper, =E2=80=9CPRINCIPLES FOR TECHNOLOGY-ASSISTED CONTACT-TR= ACING=E2=80=9D: https://www.aclu.org/report/aclu-white-paper-principles-technology-assisted= -contact-tracing [1] Data Rights for Digital Contact Tracing and Alerting: https://contacttracingrights.org/ [2] Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic: https://arxiv.org/pdf/2003.08567.pdf --00000000000028a82205a3e6dea2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Is there interest=C2=A0in havin= g an Internet-Draft around privacy-preserving contact tracing principles? I= 've been seeing quite a few of them [0][1][2].=C2=A0

Thanks,
Shivan

[0]=C2=A0ACLU whit= epaper, =E2=80=9CPRINCIPLES FOR TECHNOLOGY-ASSISTED CONTACT-TRACING=E2=80= =9D: https://www.aclu.org/report/aclu-white-pa= per-principles-technology-assisted-contact-tracing
[1]=C2=A0D= ata Rights for Digital Contact Tracing and Alerting: https://contacttracingrights.org/
[2]= =C2=A0Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic: https://arxiv.org/pdf/2003.08567.= pdf
--00000000000028a82205a3e6dea2-- From nobody Wed Apr 22 13:35:33 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BAE3A0932 for ; Wed, 22 Apr 2020 13:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 VlNlZQzflTLv for ; Wed, 22 Apr 2020 13:35:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370B43A092A for ; Wed, 22 Apr 2020 13:35:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CFB21BE50; Wed, 22 Apr 2020 21:35:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQH7qN8ZsK-z; Wed, 22 Apr 2020 21:35:24 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B47A3BE4D; Wed, 22 Apr 2020 21:35:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587587724; bh=YfeCNF34SHyGoHra09O2/fJVV9oIU7o6jY8jEqkvJ3w=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LmncRMYrb+hKxidP9S/Zb0CrQetTurGCrudjsZdptDBI43VclsPFX5l/2gAY84XKG Eb92suE+Cj/Lt4Owx54IqGJbFBc6rokWzfmClDDjGbbR89mwsPBJrs3PO7SFxGpVoS QYewIi+TgZzCFC6T9qT1+y6537Vi2Eq5O4ZpnB/4= To: Shivan Sahib , pearg@irtf.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <8b4b82ce-0816-6215-4f9a-139c1d2f255e@cs.tcd.ie> Date: Wed, 22 Apr 2020 21:35:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ogEcdoURgiSuUttBtzx2mzTg5A8z3rT3W" Archived-At: Subject: Re: [Pearg] Contact tracing principles I-D X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 20:35:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ogEcdoURgiSuUttBtzx2mzTg5A8z3rT3W Content-Type: multipart/mixed; boundary="ZS7MqMasLoIJWPObjMnWDXOJzDrHUB3Bh"; protected-headers="v1" From: Stephen Farrell To: Shivan Sahib , pearg@irtf.org Message-ID: <8b4b82ce-0816-6215-4f9a-139c1d2f255e@cs.tcd.ie> Subject: Re: [Pearg] Contact tracing principles I-D References: In-Reply-To: --ZS7MqMasLoIJWPObjMnWDXOJzDrHUB3Bh Content-Type: multipart/mixed; boundary="------------DF5EAF7D51161E7FD6705F63" Content-Language: en-US This is a multi-part message in MIME format. --------------DF5EAF7D51161E7FD6705F63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 22/04/2020 21:20, Shivan Sahib wrote: > Hi all, >=20 > Is there interest in having an Internet-Draft around privacy-preserving= > contact tracing principles? I've been seeing quite a few of them [0][1]= [2]. I'm not sure what an I-D would add? There already seems to be a flash-oversupply of apps, proposals and of analyses in this space;-) Many of 'em are good, but we do have a lot already. Considering the time from I-D -> RFC, maybe there'd be value in an I-D that said: "Don't panic and do stupid stuff just because of horrible events"? Not sure really but we do have experience of that kind of thing in reaction to terrorist attacks. Cheers, S. >=20 > Thanks, > Shivan >=20 > [0] ACLU whitepaper, =E2=80=9CPRINCIPLES FOR TECHNOLOGY-ASSISTED CONTAC= T-TRACING=E2=80=9D: > https://www.aclu.org/report/aclu-white-paper-principles-technology-assi= sted-contact-tracing > [1] Data Rights for Digital Contact Tracing and Alerting: > https://contacttracingrights.org/ > [2] Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic: > https://arxiv.org/pdf/2003.08567.pdf >=20 >=20 --------------DF5EAF7D51161E7FD6705F63 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------DF5EAF7D51161E7FD6705F63-- --ZS7MqMasLoIJWPObjMnWDXOJzDrHUB3Bh-- --ogEcdoURgiSuUttBtzx2mzTg5A8z3rT3W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6gqosACgkQWrL68XsX K+qq7g//ZJEJa1DRE2qsnMRFQ0xsdeNHN4d2EDOdKnIsyRtbo7G2VlbGQ+1Mn0YQ hVISjQdujzNOEluUjlW0O3l/ACUSuXNhV8te0rXyBS4e2hoHVYyygZf6oCbgSf/g FzIkczz95RV1QqklbTFtKyqYZh5ZrCuwNUoHTqAFAPRe+iM9EZRwjQ3oAKkbFk0z Q9J0YfNzGuGLaVlxJDTxwJEFsSXN9WEx1THlpD4F+ARL2ZCeZKhHUWrwoqtwBt8t CBIOnt+/7eYGxIVB99d8TH4A7t+LwQHB70/Y/aKc0cynJ5LMQgu3+Bo7oUVZocHG lCQGhe7T+qJew0kTQ06BHLsZ9Uls8kpaiKwuQKgUsQ/uzBGCSRg4VKqs3x/QfzEM cGytEXXE0u0bloJzXXWszlhExg/senHtYYvpPWVgqFHdhJSAWvf1OZudH6v92tfI oZ5BtHGxmmGEBmzNxQ6HHoTG30+YbG0s5q6RUNQFdXkimZknqCs3xAM0QmW1PA1J O+2tDqKidVAZtPOFuHDUbmlz6obyYk+WdR1X0gemVni3/6Tiuk7fqqdGDp6AhxLJ XOMtpeQ5JdYDHtG7713/V5k5mIgwpuL7jbX/kIkWCIIoOE0ZDw4Di81oH6aIJr+P dmZ37LQqkSOVIwU9wLsCbQHE3Uo2DB0/sFJboN8hQqEptZgCSIA= =j6HR -----END PGP SIGNATURE----- --ogEcdoURgiSuUttBtzx2mzTg5A8z3rT3W-- From nobody Thu Apr 23 06:42:12 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FAB3A0779 for ; Thu, 23 Apr 2020 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 pCsH_8aNhufk for ; Thu, 23 Apr 2020 06:42:08 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BE43A077A for ; Thu, 23 Apr 2020 06:42:07 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id d15so5294347wrx.3 for ; Thu, 23 Apr 2020 06:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bn0y/f77zoNSmJyEiH3+na+KBovO+NJ1DugVmu3s0R4=; b=r8qkx8/qf38Riv0mKv29QaJfaKyJ6qtSRksTA+BF27ilZac5sMO7XBz0BHCKmz3Tmr +wXYb1J0OHLeTz/777hHgsz/uTBr0ijRwTITKUjzSzhBIkSxNKfGPT0MNI91lAthlpOm hAo+fezW3pywqOx4mLgPlkZe+nuDMex3GClTU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bn0y/f77zoNSmJyEiH3+na+KBovO+NJ1DugVmu3s0R4=; b=Al051kvfkjo4B9lXOTFgR6wrzYi/mB+WgpEDItyAKBZLP06EpKoTMoB4k4BEEuuI1z cEA4lnpcJH4/2J/t1YENn0LlH/kIKR0moC+SrHVp4hrY3glXDZoUB7yWUVr48t0Z+Nfh z2RuHyRnV1+9WJwvr1tsnN9acLjwjS8NF0AXodogq1bd6isuoEOMT7zRJiqBWP93hR5E yMhklDYDXst0bqKEVHhmmCMnj/B6g17NBeGU1ji36UM/5q/8EK8ptrfEkrL1b7kGzhGP 5nlAgqmf5N5dunEGlTakbTiBXsDPKuOqdxhgEwEwenzaykcHbfqsLk7tF7/polHc2Szd xchQ== X-Gm-Message-State: AGi0Pub6yAYAzremx/AshILyJgJDnY1LiNi2084R41hmEeDZm8Rlg6so V+HiggN/rszyftjCsocfDiYVbzttDJeIPIjQJI6TbQ== X-Google-Smtp-Source: APiQypLYAmpUDLSIBb6HCF911DE1lTWcgYnrVdsN3A1x3xM/Q4IG6jEO+J0B9CN8ziXzcsVvfg8GNINUPOEchEWejFw= X-Received: by 2002:a05:6000:108e:: with SMTP id y14mr5423008wrw.292.1587649326097; Thu, 23 Apr 2020 06:42:06 -0700 (PDT) MIME-Version: 1.0 References: <8b4b82ce-0816-6215-4f9a-139c1d2f255e@cs.tcd.ie> In-Reply-To: <8b4b82ce-0816-6215-4f9a-139c1d2f255e@cs.tcd.ie> From: Mallory Knodel Date: Thu, 23 Apr 2020 09:41:54 -0400 Message-ID: To: Stephen Farrell Cc: Shivan Sahib , pearg@irtf.org Content-Type: multipart/alternative; boundary="0000000000001c3e3405a3f56a84" Archived-At: Subject: Re: [Pearg] Contact tracing principles I-D X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 13:42:11 -0000 --0000000000001c3e3405a3f56a84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think what might be useful from a privacy perspective is to identify what is different about a global health crisis from authoritarian mass surveillance, deep contemplation for which a moment, many moments, have come and gone. And then learn something from this new situation. -M On Wed, Apr 22, 2020 at 4:35 PM Stephen Farrell wrote: > > Hiya, > > On 22/04/2020 21:20, Shivan Sahib wrote: > > Hi all, > > > > Is there interest in having an Internet-Draft around privacy-preserving > > contact tracing principles? I've been seeing quite a few of them > [0][1][2]. > > I'm not sure what an I-D would add? There already > seems to be a flash-oversupply of apps, proposals > and of analyses in this space;-) Many of 'em are > good, but we do have a lot already. > > Considering the time from I-D -> RFC, maybe there'd > be value in an I-D that said: "Don't panic and do > stupid stuff just because of horrible events"? Not > sure really but we do have experience of that kind > of thing in reaction to terrorist attacks. > > Cheers, > S. > > > > > > Thanks, > > Shivan > > > > [0] ACLU whitepaper, =E2=80=9CPRINCIPLES FOR TECHNOLOGY-ASSISTED > CONTACT-TRACING=E2=80=9D: > > > https://www.aclu.org/report/aclu-white-paper-principles-technology-assist= ed-contact-tracing > > [1] Data Rights for Digital Contact Tracing and Alerting: > > https://contacttracingrights.org/ > > [2] Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic: > > https://arxiv.org/pdf/2003.08567.pdf > > > > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --=20 Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --0000000000001c3e3405a3f56a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think what might be useful from a privacy perspective is= to identify what is different about a global health crisis from authoritar= ian mass surveillance, deep contemplation for which a moment, many moments,= have come and gone. And then learn something from this new situation. -M
On= Wed, Apr 22, 2020 at 4:35 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 22/04/2020 21:20, Shivan Sahib wrote:
> Hi all,
>
> Is there interest in having an Internet-Draft around privacy-preservin= g
> contact tracing principles? I've been seeing quite a few of them [= 0][1][2].

I'm not sure what an I-D would add? There already
seems to be a flash-oversupply of apps, proposals
and of analyses in this space;-) Many of 'em are
good, but we do have a lot already.

Considering the time from I-D -> RFC, maybe there'd
be value in an I-D that said: "Don't panic and do
stupid stuff just because of horrible events"? Not
sure really but we do have experience of that kind
of thing in reaction to terrorist attacks.

Cheers,
S.


>
> Thanks,
> Shivan
>
> [0] ACLU whitepaper, =E2=80=9CPRINCIPLES FOR TECHNOLOGY-ASSISTED CONTA= CT-TRACING=E2=80=9D:
> http= s://www.aclu.org/report/aclu-white-paper-principles-technology-assisted-con= tact-tracing
> [1] Data Rights for Digital Contact Tracing and Alerting:
> https://contacttracingrights.org/
> [2] Apps Gone Rogue: Maintaining Personal Privacy in an Epidemic:
> https://arxiv.org/pdf/2003.08567.pdf
>
>
--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg


--
Mall= ory Knodel
CTO, Center for Democracy and Technology
gpg finger= print :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

--0000000000001c3e3405a3f56a84-- From nobody Thu Apr 30 16:06:43 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850603A159C for ; Thu, 30 Apr 2020 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=c3KoxS0y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DILoE+NM 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 LQee4aheGe5d for ; Thu, 30 Apr 2020 16:00:33 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0A13A1551 for ; Thu, 30 Apr 2020 16:00:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AD49A751 for ; Thu, 30 Apr 2020 19:00:26 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 30 Apr 2020 19:00:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=LX6sS iFQHftlhg5ER+fIDiv4CrZpyi4Szo+cr6m4xK8=; b=c3KoxS0yywYlKUKoZn4hn v1Ni0gI1d9De9Zn6npxOIdi8mSVy5sqXtKQkVJ1vpxOFby3AT0O0ME6kqk6nDxn6 Xuf2ZRSIwL72gTDLusJAEUOCOkdeiN9Gp05G28FV7jhswSe9CSLtZqPtpo+QwAbz EnPcRIuSlAVKPA8bGDAqfrEgMRWwIBS7/7xNDmhSVsH82LS6Miqn5Vx32pb8NWHW sZkZCs2MzIuLpMZTnveQfc39c/YRGGsk4AmVY4zc6UzpDQbiuksJkXgExfzVN23u sWEth7wjShSBKhi240pmmyiWJmMmivRKDp5zD8tJlVD/X9WzcLprcv7PYaNcjS+e g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LX6sSiFQHftlhg5ER+fIDiv4CrZpyi4Szo+cr6m4x K8=; b=DILoE+NMNZWE+XM2gmpdfHwhUAJVGWkfo0HfPjTReDqUPtLSSI1FTl6PM qHegAxCjubz6DX9XjDWD6dKs/Y8G2wOaDVfK5HZndNQ6g7l9B5wjjOE+lZ9urros zPPyjdJGVccWzxmA796eDmFWSLJu/voWxYoiMfE532s3x8CCPyW2NFciCExv/6vz yj5hyRe8Ebg4XP41DPDQjAAExaY2pmrteeto+pwJTqmmPJrJSlJq624q5gh6tqmr SyED/yxrS9/noKDBr3JYZRTtBDaWVHDqLqIBUVrds2AwbAsceZWMg8z8K14Z0hvo En6Jpx5bk/CPIc7WrhyUEctGw+NkQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpedvieekjefhje eufffhgfehtdetfeeuieeuteekueevueduieduiefgtdetuefgudenucffohhmrghinhep uhhsvghnihigrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD9933C00A1; Thu, 30 Apr 2020 19:00:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <317d061c-1fdd-4c95-a24b-b9cc56fececf@www.fastmail.com> In-Reply-To: References: Date: Thu, 30 Apr 2020 16:00:05 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 23:00:56 -0000 On Sun, Apr 12, 2020, at 11:25 AM, Joseph Lorenzo Hall wrote: > (also in the github issues) >=20 > > > Comments: > > >=20 > > > * Section 3.2.1: This section describes common ways in which censo= rs use HTTP fields for filtering with a pile of references at the bottom= . Upon first read, it seemed to lack relevant citations. (For example, t= he sentence > > > > As such, "method" and "host" are the two fields used most often = for ubiquitous censorship. > > >=20 > > >=20 > > > seemed like it could stand to use a reference. However, this seems= to be covered by one of the empirical examples at the end of this secti= on. Perhaps Section 3.2 could note this structure for each of its subsec= tions? Perhaps: > > > > "The following subsections describe properties and tradeoffs of = common ways in which censors filter using application-layer information.= Each subsection includes empirical examples describing these common beh= aviors for further reference." >=20 > Looks like you did this in PR #53, thanks! >=20 > > > * Section 3.2.4.1. should probably reference draft-ietf-tls-sni-en= cryption or draft-ietf-tls-esni. (I'm happy to help word-smith that text= , if you want or need assistance!) Also, the bit about fallback to SSL (= pre TLS 1.0) seems a bit outdated. Most TLS stacks no longer implement S= SLv3 at all, for example. I might remove this bit. I might also include = a reference to [1] as further SNI-based blocking reading. >=20 > Ah, we do cite Chai 2019 a bit later but I will elevate that... and=20= > have just made changes to highlight ESNI and remove the SSL fallback=20= > bit. >=20 > > > * Section 3.3.1: Assuming that IP address filtering is efficient, = it might be worth citing [2] given that it studies the (often unique) re= lationship between address and domain. It might also be worth mentioning= DoH(443) and noting the challenges it raises for blocking parties. >=20 > Done. >=20 > > > * Section 3.3.2: Is it worth mentioning Pluggable Transports here,= especially in the context of blocking Tor? >=20 > Done. >=20 > > > * Section 3.3: I was surprised to see no mention of QUIC in this s= ection. Perhaps we could replace "TCP/IP header" references with "transp= ort header references"? The information about network addresses and port= s equally applies to TCP and QUIC, and including both seems prudent so a= s to not give the wrong impression about what QUIC exposes (or doesn't).= >=20 > Done. >=20 > > > * Section 4.4.1: There's no mention of encrypted DNS here. While i= t's true that "DNS lying" and other examples are not completely mitigate= d with stub-to-resolver encryption, it does change the threat model slig= htly. Maybe DoH/DoT are worth including? It might also be worth noting l= imited client support for DNSSEC, perhaps after this sentence: > > > "Additionally, the above mechanisms rely on DNSSEC not being deplo= yed or DNSSEC validation not being active on the client or recursive res= olver." >=20 > Done. >=20 > > > * Section 4.2.2: Is packet dropping not a form of filtering? I was= surprised to see it in the interference section. >=20 > You may be hung up on the terminology we use where Identification is=20= > doing the technical matching against a set of things one wants to=20 > censor and then Interference is actually performing the technincal=20 > action to accomplish the censorship or filtering, from the Terminology= =20 > section: >=20 > > Prescription is the process by which censors determine what types of= material they should block, i.e., deciding to block a list of pornograp= hic websites. Identification is the process by which censors classify sp= ecific traffic to be blocked or impaired, i.e., blocking or impairing al= l webpages containing =E2=80=9Csex=E2=80=9D in the title or traffic to w= ww.sex.example. Interference is the process by which censors intercede i= n communication and prevents access to censored materials by blocking ac= cess or impairing the connection. >=20 > Do we need to make this more clear? Not unless others were also confused! :-) > > > * Section 4.2.3: It's probably worth mentioning QUIC here, especia= lly as it complicates this type of attack. It might also be worth citing= recent research [3] on off-path TCP attacks, noting that the censor nee= d not be on-path to interfere with service. >=20 > (That off-path paper is awesome! Had not seen that.) >=20 > Cool, that makes sense about QUIC. I don't have a good feel for what t= o=20 > write here. How does this feel, "Note, the increasingly popular QUIC=20= > protocol is based on UDP, a connection-less transport protocol, so=20 > cannot be attacked using TCP RST packet injection." >=20 > That seems a bit weird... but it sounds like there may be more under=20= > the surface to your comment so please suggest how that text above coul= d=20 > be better cleaned up? I'd probably just say something like, "QUIC is not vulnerable to these t= ypes of injection attacks. See {{quic-draft}} for more details." > > > * I was surprised to see this recent SoK paper [4] missing from th= e references. It has a lot of additional information, particularly in Ta= bles V and VI, about different types of filtration mechanisms and how th= ey impact users (by under or over blocking). That said, integrating this= paper will be a chore. So, given that the landscape of relevant researc= h and empirical evidence will undoubtedly continue changing, perhaps we = can simply drop a reference somewhere? >=20 > That is a monster, and something I'm looking forward to digging into=20= > more. I'll drop a reference and add an Issue to read and integrate it.= Sounds good! >=20 > > > Nits: > > >=20 > > > * Section 2: SmartFilter is missing a reference. >=20 > Done. >=20 > > > * Section 3.1: "Internet Service Providers have until now been the= most frequently exploited point of control" probably also warrants a re= ference, if possible. >=20 > Changed to "Internet Service Providers are frequently exploited points= =20 > of control." >=20 > > > * Section 3.2.1: The [Verkamp-2012] reference seems broken. >=20 > Hmmm, I don't see this. The link works (=20 > https://www.usenix.org/system/files/conference/foci12/foci12-final1.pd= f=20 > ) and the reference is rendering correctly.=20 Oh, sorry, the link is working, it's the reference in the document (the = forward pointer to the references section) that's broken (not clickable)= : https://tools.ietf.org/html/draft-irtf-pearg-censorship-02#section-3.= 2.1 Please let me know if you need help with these issues. I'm happy to lend= a hand! Best, Chris