Re: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: (with BLOCK)

Eric Rescorla <ekr@rtfm.com> Thu, 17 June 2021 12:43 UTC

Return-Path: <ekr@rtfm.com>
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 D07403A1E41 for <ohttp@ietfa.amsl.com>; Thu, 17 Jun 2021 05:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com
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 5Y43IXrhnnMQ for <ohttp@ietfa.amsl.com>; Thu, 17 Jun 2021 05:43:31 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8843A1E3C for <ohttp@ietf.org>; Thu, 17 Jun 2021 05:43:31 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id j14so5240651ila.6 for <ohttp@ietf.org>; Thu, 17 Jun 2021 05:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z3BKbUC4FTDqYojmfJ7kBN1tXxqYQaWzSRUldtvrrJs=; b=AAMHkpLjH5Ds0oZW1L5vLvnZkGskd6ZCv8+VWzIn1TkVQo7EuOc9lr8TRuhvjsMSBS QNQEkfcJdEQv5MrJwSZAwYmcRe4UOg0WGsQeQjTx+3WOAtZ0GwXTF+Lm/AD2hn++h6W4 1/zBTYnyuDVcwNoG9Upn7ZzMbg00W8viqZyl4DJiPVXgsTyxa1X5CAS3aH+sww7I1k+S c389mzsFzL/z6x0KEAYmFvM/7Qp4thzYKMLA7j7HLu+Zml27765ED4PAlRO9vwCHyqtF 9EZZC2sP0L8YOjJ84Dbzjex5mZzfVtRL13sETj1FOnxj5+29W0IYmI3BfCskrxMZdTda ZqXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z3BKbUC4FTDqYojmfJ7kBN1tXxqYQaWzSRUldtvrrJs=; b=RE2qYhGdfeMZ9k8HTCn60nmzQ8iGZSHXjX4uo5/yA4lbRdAfioMFuqYTulgbFWpO3J B0Maxm1hnx/Ba6dPocnr5cxzB3Rf6qjVqShCt9tEjPKwBcPhAc1mIx/98uy2V+YqWwR+ qrjlfhAu4UfMaVl5WPyWsR+UJpIUIXxKRfnv8FmfH1sLiF5ox0DoTUU8TdvxZGbqWgo0 s//JKmuQNyPY4KH6ols+bU+C9XDXynnEON9WGyOsCjxcpMGnQwJXus2nhE4+FDP8Avyr K5tHAdzqN3y4dKPst6dYFWI1znk6na1ggmFxh2si7eKj7IE/9MiR/fQ5uhUHl+SQ2/Ii 3UHw==
X-Gm-Message-State: AOAM5304VkOzBAazr2gI/zdq7/lkD48e3YE6BstnLD6TNaHdoBs+/ZZr Cji8jGlr/fAs7jAS0OGcW3fgT2+jWhWcs9reL0J499uSu7ORag==
X-Google-Smtp-Source: ABdhPJw+85laFB/vxWy+BpBJJMqzrMlCyLq/Of769fKcOV2oVbUYz+u4dBioM8mKBI7L/ZsHR33dA/e/eocCYAhwdds=
X-Received: by 2002:a92:c5a9:: with SMTP id r9mr3270945ilt.56.1623933810014; Thu, 17 Jun 2021 05:43:30 -0700 (PDT)
MIME-Version: 1.0
References: <162383653561.1023.5027949292786523303@ietfa.amsl.com> <CABcZeBPsfxcmA2MwtqU75QikatAiNAeKuLr5A-mWsEfxq4GrcA@mail.gmail.com> <126107E9-B27C-458F-9947-691398E20969@cisco.com>
In-Reply-To: <126107E9-B27C-458F-9947-691398E20969@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 17 Jun 2021 05:42:53 -0700
Message-ID: <CABcZeBMrfL1-Qh-MU6HrCBEpQwzZFx8SyjG6_WUYQ2UkUzzZPA@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, "ohttp@ietf.org" <ohttp@ietf.org>, "ohttp-chairs@ietf.org" <ohttp-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2925f05c4f58ddd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/21EII8sQZNP4oCOxSYLqAV0iNe4>
Subject: Re: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: (with BLOCK)
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: Thu, 17 Jun 2021 12:43:36 -0000

On Thu, Jun 17, 2021 at 5:29 AM Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> Hello Eric
>
>
>
> Thank you for your detailed reply and the explanations. I still consider
> that the topic should be presented to the community during a BoF where a
> longer explanation and Q&A could be done rather than a 30-minute session at
> secdispatch.
>

Given the delay that this introduces, ISTM that this needs a bit more than
"I still consider". This is effectively just an optimization of existing
mechanisms. What's the issue?


>
> 1. A browser who wants to send telemetry back to the manufacturer
> while concealing the IP address. In this case, the browser and
> manufacturer are controlled by the same entity, who also arranges
> for the proxy, which is preconfigured into the browser.
>
>
> 2. Oblivious DoH (in a TRR configuration). In this case, the client
> and proxy might be operated by the same entity who then has an
> arrangement with the DoH server.
>
> EV> I understand the requirements and the use cases (thank you BTW), but,
> if all the pieces are from the same entity, then I wonder what is the
> purpose of the machinery ? I could understand OHTTP if the 2 proxies are
> operated by different entities but with one ?
>

First, there's likely only one proxy. Second, they're not operated by the
same entity One of them is a third party, potentially with an arrangement
with the other party.


>
> > 2/ Depending on 1/, we may expect that just a couple of intermediaries
> will
> > exist, this leads to centralization to a couple of parties but also
> introduces
> > a single point of failure, scalability issues, and easier censorship.
>
> This is irrelevant for the use cases of interest, as described above.
>
> EV> agreed if this is limited to those use cases but it can obviously be
> extended to any HTTP session.
>

Not easily, no. It requires changing the origin server and then some
unspecified and difficult to specify discovery mechanism.

As I said, I'm really struggling to see the objections here, given that
we're already standardizing a generic proxying
system (MASQUE). Can you explain your reasoning?>

-Ekr

Ohttp@ietf.org