Subject: [Ohttp] Request to Charter a New Working Group: Oblivious HTTP (OHTTP)

From: IESG Secretary <[email-masked]>
Date: Mon, 07 Jun 2021 11:30:12 -0700

The IESG has received a request to charter a new working group, 
Oblivious HTTP (OHTTP).  The proposed charter, which is a work in 
progress, can be found here:

<https://datatracker.ietf.org/doc/charter-ietf-ohttp/>

The charter will be discussed on the <[email-masked]> mailing list,
which can be subscribed to here:

<https://www.ietf.org/mailman/listinfo/ohttp>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 8 Jun 2021 12:10:08 +0200

Hi IESG,

Martin's draft is interesting, but I have several questions:

 1. How is the key configuration authenticated and retrieved?  I *think*
    the intent is that a direct HTTPS request is made, but it's not
    clear.  Is it to a /.well-known something or other?  Is it a GET or
    a POST?
 2. Is the use of this work likely to help miscreants more than those in
    need of privacy?
 3. Should we expect session capabilities be built in at higher layers
    through identifiers passed in forms?

I want to spend just a little time on (2).  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?  It also seems that this 
tooling will hamper lawful intercept, *unless* session mechanisms are 
re-established in the content, in which case, aren't we going to bring 
on a rather large retooling?  And if so, will the ends of the draft 
actually be met?

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?

I am *asking* these questions, but I would rather that they get properly 
discussed and answered before the WG is approved.  What I would hate to 
see is a lot of effort take place to land people right back to where 
they were.

Eliot

On 07.06.21 20:30, IESG Secretary wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jun 2021 15:16:17 -0400

Eliot Lear <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Jun 2021 12:41:41 -0700

> queries to get better anonymization (and probably, more resiliency for DNS).

I used to believe a variation of that, that if users wanted to hide the 
IP address of the client sending DNS requests, they could just as well 
use a VPN and there would be no need for such "oblivious DNS" service. 
But it turned out that oblivious DNS was easier to deploy than VPN 
services, and also had some very nice privacy characteristics. I think 
that oblivious HTTP has the same potential, splitting the processing 
between an initial proxy that knows the client but does not know the 
requested URL, and an oblivious proxy that knows the requested URL but 
does not know the source IP address of the client.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jun 2021 16:36:34 -0400

> I used to believe a variation of that, that if users wanted to hide the IP
    > address of the client sending DNS requests, they could just as well use a VPN
    > and there would be no need for such "oblivious DNS" service. But it turned

I guess that the degenerate case of a p2p DNS is personal VPN.

    > out that oblivious DNS was easier to deploy than VPN services, and also had
    > some very nice privacy characteristics. I think that oblivious HTTP has the
    > same potential, splitting the processing between an initial proxy that knows
    > the client but does not know the requested URL, and an oblivious proxy that
    > knows the requested URL but does not know the source IP address of the
    > client.

You have two proxies here.
I didn't think that the oblivious HTTP mandated two.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 9 Jun 2021 13:05:05 +0200 (CEST)

> Il 08/06/2021 21:16 Michael Richardson <[email-masked]> ha scritto:
> 
>  

If the same entity controls the proxy and the target, what's the actual gain in privacy?

Also, if this were to be the actual deployment model, we would again be building a huge centralization mechanism for the entire web. I am always baffled by how a community that often seems obsessed with potential censorship and surveillance by governments then actively adopts architectures that foster potential censorship and surveillance by private companies, or create new gatekeeping opportunities.

More precisely, the risk is that this model would foster the birth of something that I'd call a "RDN" - request delivery network. Let's suppose that, like for CDNs, we end up with very few global providers managing the proxy layer. What happens if one of them goes down? What happens if they agree among themselves, or are forced by external factors, to deny requests from or to specific addresses, networks, or countries? Also, why should someone provide such a service, if they don't find ways to monetize the data? Is this creating economic incentives to attack the very privacy that the new architecture is supposed to offer? Or to ask application developers for money? Or to make certain client applications faster than their competitors by refusing service to the others, or by providing downgraded service to some of them?

This may or may not happen, depending on how many proxies will actually be available, but given the degree of consolidation that we're seeing in similar services, I would expect this concern to be recognized and addressed from the start. I didn't see any such consideration in the draft or in the charter.

Also, I did not see any requirements taking into account that, after all, there are sources that need to be recognized (e.g. bots) and destinations to be blocked permanently (e.g. illegal content) or depending on who the user is (e.g. parental controls). This should also be addressed explicitly by any proposal.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy