Subject: [Ohttp] Martin Duke's No Objection on charter-ietf-ohttp-00-00: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 16 Jun 2021 15:20:39 -0700

Martin Duke has entered the following ballot position for
charter-ietf-ohttp-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ohttp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support this work, although it was not easy to find a record of the
discussion that kept this out of httpbis, which seems like the obvious home.

I'm satisfied (via email and draft-thomson) that answers to these questions
exist, but the charter could use some more explanation of the server/proxy
relationship.  I assume that the proxy can't see the request targets, and thus
there must be a habitual relationship between the two. But these have to be
controlled by independent entities to provide any privacy benefits. What
server/proxy identity is the client authenticating in its own connection?

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 08:26:47 +1000

Hi Martin,

On Thu, Jun 17, 2021, at 08:20, Martin Duke via Datatracker wrote:
> relationship.  

The proxy provides a resource (identified by a URL) that the client sends encapsulated requests to.  Any request the proxy receives is forwarded to a resource (identified by a URL) at the server.

For the purposes of making the first request, the client authenticates the proxy.  The encapsulation on the request ensures that only the server can remove the encapsulation.  So in a sense it doesn't matter what the proxy does with it, but the proxy is expected to authenticate the server.  As far as making requests and authenticating servers, this is just how HTTP works.

> I assume that the proxy can't see the request targets, and thus
> there must be a habitual relationship between the two. 

Yes.  Habitual == fixed on a per-resource basis.

---

From: Martin Duke <[email-masked]>
Date: Wed, 16 Jun 2021 15:36:00 -0700

Yeah, it makes sense. We don't need the design in the charter, but some
sense of the requirements that drove the design would be helpful.

Is service discovery in scope? Will example.com tell me via alt-svc or
something that example.proxy.com can give me oblivious access to the same
resources?

On Wed, Jun 16, 2021, 15:27 Martin Thomson <[email-masked]> wrote:

> The proxy provides a resource (identified by a URL) that the client sends
> encapsulated requests to.  Any request the proxy receives is forwarded to a
> resource (identified by a URL) at the server.
>
> For the purposes of making the first request, the client authenticates the
> proxy.  The encapsulation on the request ensures that only the server can
> remove the encapsulation.  So in a sense it doesn't matter what the proxy
> does with it, but the proxy is expected to authenticate the server.  As far
> as making requests and authenticating servers, this is just how HTTP works.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 09:13:09 +1000

On Thu, Jun 17, 2021, at 08:36, Martin Duke wrote:
> something that example.proxy.com can give me oblivious access to the 
> same resources?

The charter does not include that, so I would say that a recharter would be needed to add that capability.  There are a bunch of questions that come up when it comes to discovery.  (In case you are interested, https://github.com/unicorn-wg/oblivious-http/issues/19 lists a few things that might be discovered.)

---

From: Martin Duke <[email-masked]>
Date: Wed, 16 Jun 2021 16:24:57 -0700

If so, then let's explicitly  rule that out in the charter.

On Wed, Jun 16, 2021, 16:13 Martin Thomson <[email-masked]> wrote:

> The charter does not include that, so I would say that a recharter would
> be needed to add that capability.  There are a bunch of questions that come
> up when it comes to discovery.  (In case you are interested,
> https://github.com/unicorn-wg/oblivious-http/issues/19 lists a few things
> that might be discovered.)
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 16 Jun 2021 16:26:20 -0700

> If so, then let's explicitly  rule that out in the charter.

+1 -- that seems like a sensible thing to do. 

Best,
Chris

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 09:29:32 +1000

> If so, then let's explicitly  rule that out in the charter.

Sorry for not checking the text, but the proposed charter already says:

The working group will not describe how encryption keys are obtained.  The
working group will not define any methods for discoverying proxy or server
endpoints; specific uses of the protocol will need to describe discovery methods
or rely on configuration.

I thought that was pretty clear, but then I wrote it and I don't trust my own judgment in these things.