Re: [Ohttp] Discovery

Mark Nottingham <mnot@mnot.net> Fri, 18 June 2021 07:21 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 035023A4048 for <ohttp@ietfa.amsl.com>; Fri, 18 Jun 2021 00:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=rSbnS11Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GxgKCVM3
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 bDZZ_tldNL6C for <ohttp@ietfa.amsl.com>; Fri, 18 Jun 2021 00:21:15 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24B63A4046 for <ohttp@ietf.org>; Fri, 18 Jun 2021 00:21:14 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EE34E5C00D5; Fri, 18 Jun 2021 03:21:12 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 18 Jun 2021 03:21:12 -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 JQtnrN6gQ/5gZYi5DGhtqJtPeRamGPkk8f2Y63Mmis=; b=rSbnS11Q/ZyUhV008 bfh/HwZT6fXp74iRNLsOs8cNW9mUyGiM4EwT5RE53VWkHXWVYgmcTKbRPs0wplJ8 p+nuormmLOiO68cOh3v2+ivIA58zWC6GUbjVptECd754i81YEic7xp8b54cAKlhr i/eZO0HYucKTM8EmqHj/a0GdmfprLGYWZMraS3VKmdsw272YF1hLdENnuLwHclpx 7Iqzu5wBHNUH/kEPGiugEHmSLt5Iay+6Q5pkhvZT6mUgdNYZeUAxwlplY0ajVeDG NMBPGlXaxIf12xNgWMEm3JwHh8QIbGfG/hyDq4jRHPzFv/Dyi2qy7eKR9gz3LN1f 7M6nA==
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=kJQtnrN6gQ/5gZYi5DGhtqJtPeRamGPkk8f2Y63Mm is=; b=GxgKCVM3UTGeBBV15uLTL3N8WRSba/YzTX05/FyYUkETveiSKltjISRcr 0HPvFWsq6C7faIC96zAx5kUmQuUJi4nVQkfWyrW8c3/yIMk1eD0PWr97PxptBPBl ebBkOLzsPy0Ar1rmYcyki6G04Ko0GxTLc7BDpRwlpRNEv0yBAslZTLP0NOhfrD+R 6Y1vuJ7bLutpChRRQQrlnMjeh5XmOe3CS15CpTrzWQEqVyG9E/aswuquigHG5kW0 KKaJ1E/9G8rsSm8bh8Adcmn9X1EBV1WdpJqwFUL7j97rwriQv+RK4xylkyN8QVT7 Lo1D5I+ubox+en3x9Isxw4Ex39wfQ==
X-ME-Sender: <xms:Z0nMYM3VRbOWngyYeFUz5nIcRdKzh_vr50rdhG1xsO7gdTfWscq3Kg> <xme:Z0nMYHFSxDlLAWFb1Tv2cwrXTrFrpT784dX7nAmnEMLsGXBxSqkyH2M9lywTv12SI 2j6LEpo617KpCAErg>
X-ME-Received: <xmr:Z0nMYE74NPAs6DzIU9jQyNuDDEEna-E1aab84MkV3rB2R38Zuvsj2aX_wfbVzC-mGSixCq8bHMWFqaClAFCKc1YnWNJEj8vffBKaOUlr0IFwUM43Yb_-tiWq>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefvddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeu teetnecuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:Z0nMYF05b67-wez0f7PrrfyIEqu4RcX0qUQiaFqR6sEYr2I0RvbFvg> <xmx:Z0nMYPG-5PZZp8V8PTYgMxVqRFGPSZ2KmL5ME3UZ8p4TNfAqi2bm6w> <xmx:Z0nMYO9uBCiSegPPZHDrJbvAzW4sWWPD_yIWJqH_zENQ5rZ4xrZpaQ> <xmx:aEnMYHAjrEgFZ-mznwluhGPTXt9Zqm5AxTYyBJ12N3rcjIj2CBKQDQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Jun 2021 03:21:10 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <c57ed5b0-c17a-0bca-f42a-dafaa1725792@lear.ch>
Date: Fri, 18 Jun 2021 17:21:05 +1000
Cc: ohttp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F7246CE-589A-4B34-B514-AFA0F640A384@mnot.net>
References: <D8268CF8-94DA-4E91-9286-4E45B8E26CB6@mnot.net> <c57ed5b0-c17a-0bca-f42a-dafaa1725792@lear.ch>
To: Eliot Lear <lear@lear.ch>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/Y-y_-Hk8T4gDEbFHe9hc1hnt7J4>
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 07:21:21 -0000

Eliot,

> On 18 Jun 2021, at 4:26 pm, Eliot Lear <lear@lear.ch> wrote:
> 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.  

I'm a bit familiar with that; for example, I designed and ran a global proxy deployment for a Fortune 25 company. That company no longer exists as an independent entity, but the experience was enlightening.


> 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.

To be clear, you're talking about exfiltration across MITM TLS proxies -- i.e., those that have a CA pre-configured on the client so that the network operator can intercept, read, and potentially change traffic as they see fit, correct?

If we're going to talk about what we shouldn't condone, I'd start there...

In any case, a similar approach can be taken. If someone has access to the machine to install a MITM cert, they can configure the machine to stop or re-route this mechanism. You may be worried that some vendors may demur from making that easy to do, but that's a problem for the market to solve, not the IETF. This should not affect the design of the protocol.


> 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.

Those risks are present with or without proxies of any sort. What it sounds like you're concerned about is the effectiveness of 'solutions' (e.g., DLP, other forms of monitoring) which rely on all DNS going through the resolver advertised via DHCP, and/or ones that envision all TLS traffic being subject to MITM through a configured CA.

The approach above covers that.

So I don't see how any of this is relevant to the Subject of this thread. Do you have a use case which requires discovery? Or is it just that you wish it possible to force obligatory use of a discovery mechanism upon others?


>> 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.

Search for 'WPAD vulnerability' and then let's talk.

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