[Ohttp] Is the use of this work likely to help miscreants more than those in need of privacy?
Eliot Lear <lear@lear.ch> Tue, 15 June 2021 06:43 UTC
Return-Path: <lear@lear.ch>
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 A94BC3A22BB for <ohttp@ietfa.amsl.com>; Mon, 14 Jun 2021 23:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 Ug-0RdFsTZ1r for <ohttp@ietfa.amsl.com>; Mon, 14 Jun 2021 23:43:27 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 F1E833A22B4 for <ohttp@ietf.org>; Mon, 14 Jun 2021 23:43:26 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::6] ([IPv6:2001:420:c0c0:1011:0:0:0:6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15F6hMqI297634 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 15 Jun 2021 08:43:23 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1623739403; bh=SpGQfSgQg1aOOJGlOX8SahzvhcUf5d1Ah1PXo8d5cmM=; h=To:From:Subject:Date:From; b=uL44vG09Oke2vXVGfydksSCX7eUHujR7Vjfaoj/6helzJ5O6IlZM3xDJKY1fyFfcn SpVvOxqvsNtc9U9cPo/Ef9ObkK7rtRIBPu5kwXQaUpdov/ZzIenhYJbHGqtlw6BjL0 3+ngR2vzfYtpvMQPaXs9RnHSODryKtqnLcYaakpU=
To: ohttp@ietf.org, Martin Thomson <martin.thomson@gmail.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <25f05f9a-ca84-50e1-0d36-7b4dd03ddf65@lear.ch>
Date: Tue, 15 Jun 2021 08:43:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="fas1vsS83z1JjkRT49Ij82S6f4Ef7H1Jz"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/VcQlDEQhScFxpEQ_VFkJ-Df8ie0>
Subject: [Ohttp] Is the use of this work likely to help miscreants more than those in need of privacy?
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, 15 Jun 2021 06:43:33 -0000
Hi Martin, I've broken out your response to me so that it doesn't get lost in other discussion. > 2. Is the use of this work likely to help miscreants more than those in need of privacy? > > No more so than building any other sort of infrastructure helps other miscreants. I don't ordinarily engage with this sort of comment. Better tools exist for miscreants. Let's not be quite so dismissive. I did go on to elaborate my concerns in more detail – it wasn't a throw-away comment. A particular risk here is that a participating web site gets pounded without much recourse to know which BOTs are doing the pounding. This is of particular concern when you say: > I don't think that anyone is considering these two resources being operated by the same entity. There is definitely value in having independent operation of these services. If the operator of the proxy is VERY large, there may be very little recourse. Let's take an example: if Apple were to offer OHTTP to iPhone/iPad/Safari customers, it would mean that a web site would have to cut off all of those billions of devices, disable the service entirely, or otherwise signal back to Apple alone, “for today your customers should go back to the old fashioned way.” And Apple could choose to, or simply produce an error. In other words, OHTTP could further the effects of concentration. (FWIW I have no idea if Apple would implement OHTTP, I am just using them as a hypothetical to advance the discussion.) > I do want to point to one thing here that is inherent in the design. The two main resources that are involved in the exchange - the one at the proxy and the one that does decryption - all have a fixed relationship to each other. This is deliberate because it avoids having any sort of open encrypted relay. That doesn't mean that those resources couldn't use URI parameters, but it does mean that without knowledge of the deployment, you won't naturally get the sort of flexibility that might be exploited in the same way that DNS[1] has been. When you say “the one that does the decryption” I am presuming you mean the origin server or something close to it, as opposed to the client, who is presumably also decrypting. To me this ties to discovery and agency: * If the proxy is acting as an agent of the HTTP client, then why would it fix its relationship to the server? It is merely a matter of understanding (a) whether the origin supports OHTTP and (b) whether the proxy will accept traffic for a particular origin/URL, depending on what granularity you would like. * If the proxy is acting as an agent of the server, then why should the client trust it to obfuscate its source? * And if the proxy is operating independently, then why should either end trust it at all, and why would the service be offered? I had other questions in my original email. If you'd like I could resend them. Really, I would like to understand that standardizing this work won't cause more harm than good, and I do mean the question not to be rhetorical, though it may sound so. Eliot
- [Ohttp] Is the use of this work likely to help mi… Eliot Lear
- Re: [Ohttp] Is the use of this work likely to hel… Martin Thomson
- Re: [Ohttp] Is the use of this work likely to hel… Eliot Lear
- Re: [Ohttp] Is the use of this work likely to hel… Martin Thomson