[Ohai] Proxy<>Target signals

Christopher Wood <caw@heapingbits.net> Wed, 15 June 2022 13:12 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: ohai@ietfa.amsl.com
Delivered-To: ohai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3756DC14F692 for <ohai@ietfa.amsl.com>; Wed, 15 Jun 2022 06:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.11
X-Spam-Level:
X-Spam-Status: No, score=-7.11 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_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=PBa1bTvi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XYuFL8ob
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXDJHNMaQf4h for <ohai@ietfa.amsl.com>; Wed, 15 Jun 2022 06:12:51 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7749AC14F718 for <ohai@ietf.org>; Wed, 15 Jun 2022 06:12:51 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BF41332009E3 for <ohai@ietf.org>; Wed, 15 Jun 2022 09:12:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 15 Jun 2022 09:12:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1655298770; x=1655385170; bh=57na9nODAT KSAZTDOYK3IIXydIV2g+EX8q7lltg+ras=; b=PBa1bTvifYvK19QS55uUx0KOtm ncOANC86ts9FSYnAJ8DAg+AznZXJWnCEpYk0V9YKxM7cHgERNnqish5AHqBrk8l7 d7NnEv1CS8Hkf6HJd0Vwh4RdDhlGNpSK3A0/YG+T5NTTGyrz2Tt8BHc0wo/bvB4/ p/4aeSk6Z2SZmD/FePZooltt/XhSWawAwBMP0tgleyTCRYQGAs2ktIuaon0dfYPd ir7tmfPg61nj9/zEvr3H7JzF7DSOEY27hC7EcNd2EkaUgX0pyLa24Kza9nNX0P/o 9QfHe58HovBGhqLlGf0RwpJuiYvYneHJDpyC8gYSDWMoWnPR+UDKOGNl/0xQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655298770; x=1655385170; bh=57na9nODATKSAZTDOYK3IIXydIV2 g+EX8q7lltg+ras=; b=XYuFL8obn0jrvhzuwCKMyzoC59bqWJOH5Mh94HN+9eQ1 ipmydBsyLq2xVRvu91JfFnv/NegfQ72vo2w/Z6Fg+mogjcOdGAiwbKjvA5kVhhpY E8+z+R8nQ2CWM2pWs6NBd0FDp4L0l+yN80/dPyhQy4lJjJ21wHCU7JD7yTjyFQ2S YQ1zUAEgo3NzX3ks9JoLGCQXocU0FjBpA8DHKD3opGQ5QED/fbXGdvcjyaC1Wg9u VqsLbnSAAvuisEmln9bI9xn//dfmSPeojBHPBW36sfWITE2FhYq7yVuPhFWXlMU0 ShcwjvmPZ+O65RCkEDv8DdgxY5v6vTNlr0pmCmyTew==
X-ME-Sender: <xms:0tqpYmTG4mcJZnAxhEH7HbleAdgmm6uOj_t0JxhxlnAwAQvVFUuHMQ> <xme:0tqpYrxs8t05zNrPSszgU3EwSkcp1LhojZin7a77gR2D8MElaQcEBizfioh95XGA3 _arZYk4HlaFKXnvAhQ>
X-ME-Received: <xmr:0tqpYj2MmYp1O0XUAqGNQSa4KLrhuvWF1bQEH1yMbU9mPJ_m3wqcAJ95iMvC9LBxFtu5d7ys92IsJlC3EWf0WJ0bED5b2BM8fQ4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvuddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtdejnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoegtrgifsehhvggr phhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeeuleelteeihfffgfeuvd egteehgeefudeiheetkefhtdejtdffjefghfejteetteenucffohhmrghinhepghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:0tqpYiDwfmpudypeEwtAwsjSuqn16kqfuZWQCFp60Q0Ug4cZwkdN3g> <xmx:0tqpYvjBjL38wbYy6HmzCm-pxm_TShKjun5ky2b6KWqODiIYr6WTwg> <xmx:0tqpYuoCuoygq4IGYo29VVm3i2zSl-3pXU97opanSTbcdwEQcfA8rg> <xmx:0tqpYhf7uBj7e9iNxwfFdVyzadqfN320CSq1dE8LFWvst3si0fholQ>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <ohai@ietf.org>; Wed, 15 Jun 2022 09:12:50 -0400 (EDT)
From: Christopher Wood <caw@heapingbits.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Message-Id: <024CE45F-E5EC-4203-B840-3FB8463EE750@heapingbits.net>
Date: Wed, 15 Jun 2022 09:12:48 -0400
To: ohai@ietf.org
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohai/37e7LQDLYu7CC7NEqUOmE1cVXiE>
Subject: [Ohai] Proxy<>Target signals
X-BeenThere: ohai@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Oblivious HTTP Application Intermediation <ohai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohai>, <mailto:ohai-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohai/>
List-Post: <mailto:ohai@ietf.org>
List-Help: <mailto:ohai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohai>, <mailto:ohai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 13:12:56 -0000

Hi folks,

One of the topics discussed during our meeting at IETF 113 was whether the proxy could attach client metadata to requests to the target (to use the ODoH terminology). A shadow ban bit was the primary example, initially raised in issue #66. Issue #100 also raised the possibility of other metadata, like the client geo. Based on discussion during the meeting and the corresponding issues, we have an initial PR that explains the circumstances in which this type of data can be attached to forwarded requests by a proxy:

   https://github.com/ietf-wg-ohai/oblivious-http/pull/113

Please have a look and provide feedback. We’ll merge this soon barring objections.

Related to this topic is issue #114, which considers the relation between signals sent between proxy and target. As we consider target->proxy signals like rate limits, I think we ought to consider how this might be abused to narrow the client anonymity set in surprising ways. My current thinking is that a proxy must treat client requests independently of whatever signals it receives from a target since, if this is not done, requests the target sees may be correlated to past requests. I’d appreciate if folks would take a look at that issue and chime in ahead of 114. I’d like to discuss the issue then.

Thanks,
Chris