Re: [Ohttp] Meaning of "usage constraints" in charter

Mark Nottingham <mnot@mnot.net> Tue, 27 July 2021 22:48 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: ohttp@ietfa.amsl.com
Delivered-To: ohttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EF13A0D30 for <ohttp@ietfa.amsl.com>; Tue, 27 Jul 2021 15:48:42 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=WEwq2Dhq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UIGhAkl8
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 DRTZrgYamTok for <ohttp@ietfa.amsl.com>; Tue, 27 Jul 2021 15:48:36 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064F53A0D28 for <ohttp@ietf.org>; Tue, 27 Jul 2021 15:48:35 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 17F585C0156; Tue, 27 Jul 2021 18:48:35 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 27 Jul 2021 18:48:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=K 4SSaQYtxy/qsY+wU5Xd6Mi5hzSZy+fnloT7xWUvvf0=; b=WEwq2DhqA55/Ed1VJ DVbxEk9U6DXg0B51REWCRmmneq/ZJuBki3800x2I42j/Xd6eb/CKGMZU4/YlzrHU 2UkVifjRbw6stutFXCRfUEyWkBXDQAKfblWU/mGolegDPv8VEQM6JTIm87RXxU0b GO6B55T6oTU03ldiD5LPvpXJ7+DBlqJpYl2jy4QojCSO3fwoHd51JsucNd4/u/WW Kimgh7sMYfg6jITmowKnxfLy+/NZ9wAIy6jKmLi7mn9CyLdSsdMR5epLOe5k05Hy yd5rOOc10qc6mw0IRWZhWEOSxTcFAO43ftMgmzH6Hv4Wm1Yb2vEnzs6ySA80RpHv GLSxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=K4SSaQYtxy/qsY+wU5Xd6Mi5hzSZy+fnloT7xWUvv f0=; b=UIGhAkl8zHkFtq9PUnCYjyihT03qbHMyWj7X/WYI+R0+9e0H9ZUqQCPSb lRnaVgcEjnQaxu/DxJqp8Y1nM15bzQAsbrUGaDb57Se1yOcSxopgi8VNU48XSAgu sGmQO2XTm8dSBUs+9mIRpGgbJ1in2rjZr94fqHG4S2NG20bphfmXDqOk7d+BfKh0 ufW8lKNohtA5LvRMFNj6zJIjlrfSIDdAyScLNGfSbeWLrF43uzZ0Q7igcIVEUXq4 LkQFlCJ0byTnUtTSlNZ+xAJb1wyBuQv7tC14JJg4VHQZ7/lHerxXvWRAkcP4V4zL Hn8mZWw+iQnbh/QkxdkdO2z0o+Djg==
X-ME-Sender: <xms:QI0AYQLmrE00FpKTOxVRKcvLAr1dh8XJDyUlQfEojfIxH3vQDtGMxQ> <xme:QI0AYQLXEXc4Qpog7Y9J2qSMUTxb72wdHx21LLIx62ParopbyGoy7VAEsizuzE1Nn s8CStSuAMYzPwS3Sw>
X-ME-Received: <xmr:QI0AYQuw_KJIrzMxUu6DYTMCGGz0MR7g5dmAtvYDTxXIyy1PT8QbLfTyAdTBipsFKEOA2KAWmoCfS-RhQ9LLbJGMGPLh0FNZiTpQDkHc7PeeQZrDkG3v-ojH>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:QI0AYdZCyIRW7NVlTjbWflgr5Sm0O6SFkgibZ4Z6H78wCQH3qVeMBw> <xmx:QI0AYXZ93OIjFA5b1zO1IDPE2dkUnXhTmeNZOIwa8gE1ba1vLsG0fA> <xmx:QI0AYZALSC4feAPkuhwge4dO2ebdxmBbJa_id1A37AYcHypluBsImw> <xmx:Q40AYSwcConk0bKPbdlR7tT_Ii4C7lusTmW3PH3cbGFWx7fraLriug>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Jul 2021 18:48:31 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAEm8Q12iFmFqsyPo_GuGtA8OtyNfHZ815Ly9ZNpUAc=SVXd-ZQ@mail.gmail.com>
Date: Wed, 28 Jul 2021 08:48:28 +1000
Cc: Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "ohttp@ietf.org" <ohttp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4C718F6-E1BF-43D0-B20D-0A05792A8AF9@mnot.net>
References: <HE1PR0702MB37721B3DC9958D6FECAC24A595E99@HE1PR0702MB3772.eurprd07.prod.outlook.com> <164791655.178472.1627390180052@appsuite-gw1.open-xchange.com> <CAEm8Q12iFmFqsyPo_GuGtA8OtyNfHZ815Ly9ZNpUAc=SVXd-ZQ@mail.gmail.com>
To: Thomas Mangin <thomas.mangin@exa.net.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/31G2vWyW3l3q7miLOW0uOLuUaM4>
Subject: Re: [Ohttp] Meaning of "usage constraints" in charter
X-BeenThere: ohttp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Oblivious HTTP <ohttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohttp>, <mailto:ohttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohttp/>
List-Post: <mailto:ohttp@ietf.org>
List-Help: <mailto:ohttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohttp>, <mailto:ohttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 22:48:43 -0000

> On 28 Jul 2021, at 6:43 am, Thomas Mangin <thomas.mangin@exa.net.uk> wrote:
> 
> This is why if we want to give users control of who they want to trust as proxies, there should be a way for them to detect and select who they trust to protect their privacy.

There's the rub. If a discovery mechanism allows a network to impose a proxy upon a user (which is by definition how most work), it can be used to take a choice *away* from them. Again, HTTP has *no* standard intermediary discovery mechanism, and the one non-standard one we have is widely used to impose policy upon users, not give them "choice."

A more user-focused approach would be to require implementations to allow a user to explicitly choose an arbitrary proxy. Even then, a great amount of care is required -- if the choice is too easily delegated, that can be an attack vector. If there are too many choices, that leads to cognitive overload -- again, bad for users.

That requirement isn't evident on the wire, nor is it an interop requirement, so whether it's in-scope for the IETF is questionable. Also, arguably a user already makes a trust choice when they choose an implementation -- so bundling together the implementation and the proxy choice can be seen as reducing their cognitive load while still allowing them the freedom to choose another implementation (I don't know that I necessarily agree with this argument, but it's not prima facie invalid).

At any rate, the list of choices that are likely to help the user is _not_ "here's a bunch of different proxies that have advertised themselves to me over the networks you've been on." That's like saying that CAs should be discoverable. Much deeper and more nuanced trust relationships are required.

I'm fine if folks want to continue to talk about the use cases for these proxies, but will strongly oppose any requirement to require support for discovery of them from a network, for the reasons above. 

Cheers,


--
Mark Nottingham   https://www.mnot.net/