Subject: [Ohttp] Meaning of "usage constraints" in charter

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jul 2021 11:54:02 +0000

Hi,

I have a question regarding this paragraph in the updated charter:

The OHTTP working group will include an applicability statement that
documents

the limitations of this design and any usage constraints that are necessary
to

ensure that the protocol is secure.  The working group will consider the

operational impact 

What is actually meant with usage constraints in the charter here? 

To me it appears that for OHTTP to successfully meet its privacy preserving
goals the HTTP endpoint that like to preserve its privacy not only need to
have a method of getting the message to the HTTP server that doesn't reveal
the requestors IP address or otherwise makes it easy to figure out the
origin. A method for this is clearly described in the charter that has
certain properties. 

However, the other aspects appear that one need to have good guidance on how
to generate HTTP requests that doesn't leak tracking information to the
server anyway. It is not clear if the usage constraints are intended to
describe best practices for how one construct HTTP requests that is
difficult to profile and track. I can understand that some of these aspects
may be dependent on the usage, but without a document discussing what HTTP
headers etc that can be fairly safe to use, the limitations on usage may not
be clear, and possible to interpret beyond any well known usages that a
"usage constraint" may discuss.

I think this part would be highly relevant for OHTTP but also usable by
others that may use another mechanism to achieve the transport of the HTTP
messages in a privacy preserving way. 

Cheers

Magnus Westerlund

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 27 Jul 2021 14:49:40 +0200 (CEST)

>     Il 27/07/2021 13:54 Magnus Westerlund <magnus.westerlund=[email-masked]> ha scritto:
> 
> 
> 
>     Hi,
> 
> 
>     The OHTTP working group will include an applicability statement that documents
> 
>     the limitations of this design and any usage constraints that are necessary to
> 
>     To me it appears that for OHTTP to successfully meet its privacy preserving goals the HTTP endpoint that like to preserve its privacy not only need to have a method of getting the message to the HTTP server that doesn’t reveal the requestors IP address or otherwise makes it easy to figure out the origin. A method for this is clearly described in the charter that has certain properties.
> 
> 
>     However, the other aspects appear that one need to have good guidance on how to generate HTTP requests that doesn’t leak tracking information to the server anyway. It is not clear if the usage constraints are intended to describe best practices for how one construct HTTP requests that is difficult to profile and track. I can understand that some of these aspects may be dependent on the usage, but without a document discussing what HTTP headers etc that can be fairly safe to use, the limitations on usage may not be clear, and possible to interpret beyond any well known usages that a “usage constraint” may discuss.
> 
Actually - others may correct me if I'm wrong - the reason for this mention of "usage constraints" and for the applicability statement in general is that several people (included myself) suggested that the charter should include an analysis of the operational issues, of the potential effects in terms of Internet centralisation through a likely concentration of OHTTP proxy services, and of non-technical impacts on other parties that need access to traffic information. As a reaction, it was said that this protocol is only meant for use in specialized cases such as browsers sending telemetry to their own home, i.e. the origin and the destination of the traffic being controlled by the same party, and one of the proxies being provided by a third party under a direct contractual agreement, without the user having to pick a proxy operator or choose among multiple ones; and this makes the above concerns redundant.

I am still not convinced that this makes sense, as one would expect that once the protocol is published it will be deployed in many other ways which will bear significant policy and operational impacts, and so these impacts should be discussed since the beginning. But it's just my opinion.

-- 

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

---

From: Andrew Campling <[email-masked]>
Date: Tue, 27 Jul 2021 15:22:04 +0000

> What is actually meant with usage constraints in the charter here?

I took this to mean that WG will ensure that any use case limitations and the reasons for them are clearly spelt out, either within the protocol RFC or in a separate document.  No doubt others will share their views.

Andrew

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 27 Jul 2021 21:43:37 +0100

On Tue, 27 Jul 2021 at 13:49, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> I am still not convinced that this makes sense, as one would expect that
> once the protocol is published it will be deployed in many other ways which
> will bear significant policy and operational impacts, and so these impacts
> should be discussed since the beginning. But it's just my opinion.
>
I very much second your opinion. It does not matter what the draft/RFC says
the use cases are or should be. Once it is documented, it can be
implemented and used in other ways. So any "restrictions" in the document
is going to be very much advisory, at best. Brave implemented IPFS, search
engine, they may decide to run their own proxies and make all traffic
OHTTP, no one could stop them.

This is why if we want to give users control of who they want to trust as
proxies, there should be a way for them to detect and select who they trust
to protect their privacy.

Thomas

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jul 2021 08:48:28 +1000

> On 28 Jul 2021, at 6:43 am, Thomas Mangin <[email-masked]> wrote:
> 
> This is why if we want to give users control of who they want to trust as proxies, there should be a way for them to detect and select who they trust to protect their privacy.

There's the rub. If a discovery mechanism allows a network to impose a proxy upon a user (which is by definition how most work), it can be used to take a choice *away* from them. Again, HTTP has *no* standard intermediary discovery mechanism, and the one non-standard one we have is widely used to impose policy upon users, not give them "choice."

A more user-focused approach would be to require implementations to allow a user to explicitly choose an arbitrary proxy. Even then, a great amount of care is required -- if the choice is too easily delegated, that can be an attack vector. If there are too many choices, that leads to cognitive overload -- again, bad for users.

That requirement isn't evident on the wire, nor is it an interop requirement, so whether it's in-scope for the IETF is questionable. Also, arguably a user already makes a trust choice when they choose an implementation -- so bundling together the implementation and the proxy choice can be seen as reducing their cognitive load while still allowing them the freedom to choose another implementation (I don't know that I necessarily agree with this argument, but it's not prima facie invalid).

At any rate, the list of choices that are likely to help the user is _not_ "here's a bunch of different proxies that have advertised themselves to me over the networks you've been on." That's like saying that CAs should be discoverable. Much deeper and more nuanced trust relationships are required.

I'm fine if folks want to continue to talk about the use cases for these proxies, but will strongly oppose any requirement to require support for discovery of them from a network, for the reasons above. 

Cheers,

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