Re: Request to Charter a New Working Group: Oblivious HTTP (OHTTP)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 08 June 2021 19:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422203A3A84; Tue, 8 Jun 2021 12:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 TK2douCtLYeq; Tue, 8 Jun 2021 12:16:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290423A3A80; Tue, 8 Jun 2021 12:16:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9684438CB0; Tue, 8 Jun 2021 15:17:06 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a6FkaBXcLibk; Tue, 8 Jun 2021 15:17:02 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 49C7538CAF; Tue, 8 Jun 2021 15:17:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7696B486; Tue, 8 Jun 2021 15:16:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@lear.ch>, 'IESG' <iesg@ietf.org>, ohttp@ietf.org, ietf <IETF@ietf.org>
Subject: Re: Request to Charter a New Working Group: Oblivious HTTP (OHTTP)
In-Reply-To: <d8932acb-397b-25b9-7bab-50c1a313d583@lear.ch>
References: <162309061157.32548.930649503797136245@ietfa.amsl.com> <d8932acb-397b-25b9-7bab-50c1a313d583@lear.ch>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 08 Jun 2021 15:16:17 -0400
Message-ID: <4800.1623179777@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gwuMaozP0tiklYup_T_p6S1V7p4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 19:16:30 -0000

Eliot Lear <lear@lear.ch> wrote:
    > Is this same service going to further harm clients by making it even more
    > difficult to block known malicious web sites?  Not only would a local
    > deployment not be able to do this, but proxies themselves wouldn't be able to
    > spot malware.  Combine that with some rather impressive phishing capabilities
    > of bad actors, and aren't we just hamstringing our ability to put down
    > malware attacks?

Without taking a position on the fundamental questions you ask, my
understanding is that the proxy would be run by an entity that had a lot of
properties, and that wished to provide pseudonymous access to them.
Candidates that I can think of would include: google, godaddy, azure, ec2,
cloudflare, *.gov, *.gc.ca, wordpress hosting companies, ... and that the target
properties would be configured with some trust in the proxy system.

> If what we are doing is
> standardizing tooling and providing libraries for BOTnets to operate against
> web sites, where the web site has no recourse when it is attacked, then why
> would anyone implement this? 

Given the relationship that I assuming above, then the web sites would be
able to communicate back to the proxy, and would be able to kill traffic
there.

BUT: A concern that I have is that in the already very assymetrical
     relationship between big property owners and small ones, this protocol
     makes it even more uneven.

So I would urge us to get a clear idea of what the possible costs of this
protocol are.  What are the benefits?  Like your blog and facebook questions
about Tor, I'm not convinced that the privacy benefits of this are large.

I didn't think oblivious-DNS was particularly useful either, because it was
basically just turning stub resolvers into mutated full resolvers, without
actually teaching them to do DNSSEC.   If they could do DNSSEC, then we could
trust answers from any place, and then we could do some kind of p2p DNS
queries to get better anonymization (and probably, more resiliency for DNS).

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide