Subject: [Ohttp] Discovery (no)

From: Thomas Mangin <[email-masked]>
Date: Mon, 26 Jul 2021 15:21:26 +0100

Hello, I just found this mailing list/group and I am curious.

Mark makes a good point but it is possible to implement a HTTP proxy using
the HTTP specification, and the specification is for a protocol which can
work without proxy.

I am unclear on what this group intend to standardise if part of the
protocol is left undocumented: it will prevent interoperability and may
lead to multiple incompatible different key discovery mechanism and
therefore non-interroperable implementations.

If end-to-end interoperability is not an objective I am at loss as to why a
multi-stakeholder group is being created for this protocol.

Thomas Mangin

Operational and Technical Director
Exa Networks Limited

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 26 Jul 2021 08:04:44 -0700

On Mon, Jul 26, 2021, at 7:21 AM, Thomas Mangin wrote:
> Mark makes a good point but it is possible to implement a HTTP proxy 
> using the HTTP specification, and the specification is for a protocol 
> which can work without proxy.
> 

Can you elaborate on what OHTTP interoperability problems arise if two different discovery mechanisms are used? 

Best,
Chris

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 26 Jul 2021 18:02:24 +0100

Good point, please excuse my bad wording, there can no be interoperability,
as there is no way for someone to implement a working end-to-end connection
based on the RFC and check it against another implementation. It is enough
to implement the defined components but not a full solution.

Thomas

On Mon, 26 Jul 2021 at 16:05, Christopher Wood <[email-masked]> wrote:

> --
> Ohttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ohttp
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jul 2021 10:09:16 -0700

On Mon, Jul 26, 2021 at 10:02 AM Thomas Mangin <[email-masked]>
wrote:

> Good point, please excuse my bad wording, there can no be
> interoperability, as there is no way for someone to implement a working
> end-to-end connection based on the RFC and check it against another
> implementation. It is enough to implement the defined components but not a
> full solution.
>

I don't believe that this is correct.

The basic insight here is that in most of the cases of interest there is
*already* a relationship between the client and the origin server and that
relationship is already worked out of band in some way. So that piece does
not need interop.

-Ekr

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 26 Jul 2021 20:34:33 +0100

> relationship is already worked out of band in some way. So that piece does

Thank you Eric,

I feel we will have to agree to disagree: if developers can not create two
interoperable implementations from a draft/RFC alone, this is not a
complete document. For me, it would be like leaving out the port from the
HTTP protocol.

There may have been "considered reasons" why the draft authors decided to
leave this out, but this does not change the point.

Thomas

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jul 2021 12:37:23 -0700

On Mon, Jul 26, 2021 at 12:34 PM Thomas Mangin <[email-masked]>
wrote:

> complete document.

They *can* create an interoperable implementation. The entities that
interoperate are (a) the client/origin-server and (b) the proxy. It's just
that the client/origin server are in two pieces. But that's no more a
problem than that in order to do QUIC you need a QUIC stack and a UDP stack
but there's not really a standardized interface that goes between them.

-Ekr

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 26 Jul 2021 21:07:27 +0100

> but there's not really a standardized interface that goes between them.

With the same argument, the port could/should be left out of HTTP RFC. You
can make interoperable implementations without it, you just need to agree
the port outside the RFC. I fail to see your QUIC parallel, I had no issue
with the QUIC drafts but I its has been well over a year since I read a
draft and I have not read the published RFC. Also there is quite a few
"end-to-end" OSS QUIC implementations where developers were able to create
QUIC clients and servers. I can not implement a OHTTP stack and make it
work with anyone, without out-of-draft discussion.

But again, I feel that it does no matter on long we discuss this on the ML,
we will probably not agree. That said, the draft encoding and components
description is very good and clear and I can see no issue with it.

Thomas

---

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

On Mon, Jul 26, 2021 at 21:07 Thomas Mangin <[email-masked]<mailto:[email-masked]>> wrote:

I feel we will have to agree to disagree: if developers can not create two interoperable implementations from a draft/RFC alone, this is not a complete document.

They *can* create an interoperable implementation. The entities that interoperate are (a) the client/origin-server and (b) the proxy. It's just that the client/origin server are in two pieces. But that's no more a problem than that in order to do QUIC you need a QUIC stack and a UDP stack but there's not really a standardized interface that goes between them.
>
> With the same argument, the port could/should be left out of HTTP RFC. You can make interoperable implementations without it, you just need to agree the port outside the RFC. I fail to see your QUIC parallel, I had no issue with the QUIC drafts but I its has been well over a year since I read a draft and I have not read the published RFC. Also there is quite a few "end-to-end" OSS QUIC implementations where developers were able to create QUIC clients and servers. I can not implement a OHTTP stack and make it work with anyone, without out-of-draft discussion.
>
> But again, I feel that it does no matter on long we discuss this on the ML, we will probably not agree. That said, the draft encoding and components description is very good and clear and I can see no issue with it.

I agree that discovery is a necessary part of the development of this protocol: if we rely on unspecified, out-of-band methods for proxies to be determined then we are open to collusion between parties, with associated loss of any privacy protections, as well as risk of further centralisation.  In my view, the WG should commit to documenting a fair, open discovery mechanism for proxies that is published alongside the main protocol.

No doubt this will come up in the BOF discussion later today.

Andrew

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 27 Jul 2021 13:30:07 -0400

Hi Andrew,

> On Jul 27, 2021, at 11:13 AM, Andrew Campling <[email-masked]> wrote:
> 
> On Mon, Jul 26, 2021 at 21:07 Thomas Mangin <[email-masked] <mailto:[email-masked]>> wrote:
>  
> > 
> > 
> I agree that discovery is a necessary part of the development of this protocol: if we rely on unspecified, out-of-band methods for proxies to be determined then we are open to collusion between parties, with associated loss of any privacy protections, as well as risk of further centralisation. 

Parties can always collude whether or not a discovery mechanism is specified.

Alissa

> In my view, the WG should commit to documenting a fair, open discovery mechanism for proxies that is published alongside the main protocol. 
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ohttp <https://www.ietf.org/mailman/listinfo/ohttp>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jul 2021 10:39:53 -0700

On Tue, Jul 27, 2021 at 10:30 AM Alissa Cooper <[email-masked]> wrote:

> On Mon, Jul 26, 2021 at 21:07 Thomas Mangin <[email-masked]>
> wrote:
>
> >
> >
>
> > With the same argument, the port could/should be left out of HTTP RFC.
> You can make interoperable implementations without it, you just need to
> agree the port outside the RFC. I fail to see your QUIC parallel, I had no
> issue with the QUIC drafts but I its has been well over a year since I read
> a draft and I have not read the published RFC. Also there is quite a few
> > But again, I feel that it does no matter on long we discuss this on the
> ML, we will probably not agree. That said, the draft encoding and
> components description is very good and clear and I can see no issue with
> it.
>
> I agree that discovery is a necessary part of the development of this
> protocol: if we rely on unspecified, out-of-band methods for proxies to be
> determined then we are open to collusion between parties, with associated
> loss of any privacy protections, as well as risk of further
> centralisation.
>
>

Indeed. Moreover, one of the key configuration questions is which proxies
you trust not to collude, and that's inherently a decision for the client.
You'll note that the question of "discovering" which trust anchors TLS
clients use is not one that the IETF addresses.

-Ekr

> Alissa
>
> In my view, the WG should commit to documenting a fair, open discovery
> mechanism for proxies that is published alongside the main protocol.
>

---

From: Andrew Campling <[email-masked]>
Date: Tue, 27 Jul 2021 18:32:28 +0000

> Parties can always collude whether or not a discovery mechanism is specified.

True, however lack of a discovery mechanism would make it trivially easy for them to do so.  No doubt the security consideration section will have to address this fully in due course, assuming that the wg is chartered.  In addition, the WG should ensure that use case limitations and the reasons for them are clearly spelt out, either in the protocol RFC or a separate document.

My concern here is that we need to see a discovery mechanism in order to provide the end user with some degree of control over the selection of proxies, otherwise these choices are left to the software developers and revelations about surveillance capitalism over last decade tells us that the latter approach would be unwise.  In addition to privacy concerns, centralisation also comes to the fore - if there isn't a discovery mechanism then it seems likely to me that the bulk of traffic will find its way to a small number of CDNs, further weakening the resilience of the Internet.

Andrew