Re: [Ohttp] Discovery

Eliot Lear <lear@lear.ch> Fri, 18 June 2021 06:26 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 C9C123A3EC0 for <ohttp@ietfa.amsl.com>; Thu, 17 Jun 2021 23:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, NICE_REPLY_A=-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 cyHHJH2umq7C for <ohttp@ietfa.amsl.com>; Thu, 17 Jun 2021 23:26:38 -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 E046B3A3EBC for <ohttp@ietf.org>; Thu, 17 Jun 2021 23:26:36 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:cc2a:2734:3e55:d830]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15I6QYk1356783 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 18 Jun 2021 08:26:34 +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=1623997594; bh=kEQvUkZMHdm6SYTX6zCykhjbGlMDjfdETz/mIwqraCs=; h=To:References:From:Subject:Date:In-Reply-To:From; b=B9pyoWFO98xQz0OnCOwv3OWgUwIVh3/YtCsxktihgPBraWC8zNxXqNNESPufdTw1s ScTZ0tstFF7NccqzDUw3gHrJ0SpB6eMJDLv0nqnC9qY9pNoCfo5kjlMC1jZaepku4+ Dugpo3snxdd7UFiF0Zl6BBZIaXjpdsCMPU6ibfbo=
To: Mark Nottingham <mnot@mnot.net>, ohttp@ietf.org
References: <D8268CF8-94DA-4E91-9286-4E45B8E26CB6@mnot.net>
From: Eliot Lear <lear@lear.ch>
Message-ID: <c57ed5b0-c17a-0bca-f42a-dafaa1725792@lear.ch>
Date: Fri, 18 Jun 2021 08:26:32 +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
In-Reply-To: <D8268CF8-94DA-4E91-9286-4E45B8E26CB6@mnot.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="iZzlUIbA6mavqHfPeYY3y2IlANq6hTtnQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/0IUfSEIFliYQviW_uAzo71yaAnw>
Subject: Re: [Ohttp] Discovery
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: Fri, 18 Jun 2021 06:26:43 -0000

Hi Mark,

On 18.06.21 03:35, Mark Nottingham wrote:
> Since discovery is coming up in a lot of the chartering comments, I want to point out that HTTP proxies in general have no standard discovery mechanism; the most we have is proxy.pac + WPAD, which are widely seen as actively harmful (especially the latter).
>
> HTTP proxying nevertheless does just fine, because the primary models -- client-selected and server-selected intermediation -- work just fine, and don't require any discovery mechanism.

If we were to run a survey of enterprise network managers, asking what 
they thought about the complexity of managing proxies, I'm quite 
confident that you would hear a woeful tale.  None of that is relevant 
here for a variety of reasons, the first of which is that the history of 
HTTP is both long and twisted around the evolving nature of the network 
and what was carried over it.  The second issue is that the proxy.pac 
file was created in the first place to answer one question: what's 
local?  That question isn't at issue here.

To me, the primary issue here is about trust and agency.  In the cases 
you mentioned, there is at least *some* relationship between the 
individual using the proxy and the proxy itself.  Here that's at least 
not clearly the case.

The use cases that have been discussed talk about O&M to manufacturers.  
That at least is concrete, where discovery isn't. It does raise issues 
about exfiltration over the top of TLS proxies.  Yes, that happens 
today, but maybe we shouldn't condone that practice.  But maybe there's 
also a way to address the O&M needs in a way that doesn't risk 
exfiltration.  In any case, understanding all the actors here is important.

The second potential use case is for DOH.  Either that is in scope and 
should be discussed, or it isn't.  That use case could present 
substantial abuse risks, particularly around botnet C&Cs, and then this 
work would be interacting with ADD.

> I think the same applies here, and would go as far as to say that requiring the specification of a discovery mechanism adds a lot of risk.

Risk to whom and why?  Seems like there are plenty of risks to discuss.

Eliot