[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