Subject: [Secdispatch] Oblivious HTTP charter draft

From: "Martin Thomson" <[email-masked]>
Date: Thu, 18 Mar 2021 12:24:33 +1100

Hi everyone,

As we discussed last week, Oblivious HTTP was dispatched to a new working group.  I've a proposal for charter text below.

After discussing with a few people, it seems like the SEC area is the best venue for this work.  It's security-focused work and this area has the best expertise in that area.  However, as noted, this will require coordination with HTTP and DPRIVE.  The former to ensure that we aren't abusing their protocol (or at least not TOO badly) and the latter to ensure that this is usable for their purposes.

Read the current text or contribute text at https://github.com/unicorn-wg/ohttp-charter

---
# Oblivious HTTP Working Group (OHTTP) Charter

In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity.

Client-server protocols like HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time.

In a setting where the information included in requests does not need to be correlated, the Oblivious HTTP protocol allows a server to accept requests via a proxy. The proxy ensures that the server cannot see source addressing information for clients, which prevents servers linking requests to the same client. Encryption ensures that the proxy is unable to read requests or responses.

The OHTTP working group will define the Oblivious HTTP protocol, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. The working group will define any encryption scheme necessary and supporting data formats for carrying encapsulated requests and responses, plus any key configuration that might be needed to use the protocol.

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 define a format for any encryption keys that are needed. The working group will not describe how encryption keys are obtained. The working group will not define any methods for discovering proxy or server endpoints; specific uses of the protocol will need to describe discovery methods or rely on configuration.

The OHTTP working group will work closely with other groups that develop the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use Oblivious HTTP (DPRIVE for DNS over HTTPS).

The working group will use draft-thomson-http-oblivious as input.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Mar 2021 09:09:18 -0400

Martin Thomson <[email-masked]> wrote:
    > After discussing with a few people, it seems like the SEC area is the
    > best venue for this work.  It's security-focused work and this area has
    > the best expertise in that area.  However, as noted, this will require
    > coordination with HTTP and DPRIVE.  The former to ensure that we aren't
    > abusing their protocol (or at least not TOO badly) and the latter to
    > ensure that this is usable for their purposes.

Remember that we can have WGs in one area, but have a responsible AD from
another area.   Also, having co-chairs with different strenghts can really
help here too.

    > # Oblivious HTTP Working Group (OHTTP) Charter

...

    > In a setting where the information included in requests does not need
    > to be correlated, the Oblivious HTTP protocol allows a server to accept
    > requests via a proxy. The proxy ensures that the server cannot see
    > source addressing information for clients, which prevents servers
    > linking requests to the same client. Encryption ensures that the proxy
    > is unable to read requests or responses.

My understanding of how the protocol works is that we are really building a
kind of hybrid HTTP/TLS proxy.  That there is some intentional blurring of
layers in order to get the desired properties.

It seems weird that TLS is not mentioned :-)

    > The working group will define a format for any encryption keys that are
    > needed. The working group will not describe how encryption keys are
    > obtained.

My understanding is that we don't need new infrastructure, because HTTPS
provides what we need.  So I think this text is unnecessary.

    > The working group will not define any methods for discovering
    > proxy or server endpoints; specific uses of the protocol will need to
    > describe discovery methods or rely on configuration.

reasonable.

I think that there may be push in the WG to provide some extension to allow
the proxy to snoop on, but not modify, the traffic.
It may be worth coding this into the charter as out of scope.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 19 Mar 2021 10:14:14 +1100

Thanks for the response Michael,

> It seems weird that TLS is not mentioned :-)

It doesn't mention IP either.  Maybe we can just take TLS as read.
 
> provides what we need.  So I think this text is unnecessary.

Maybe the draft isn't clear enough on this point.  For reasons described in draft-wood-key-consistency, key acquisition is not that simple.  The draft does mention HTTPS, but carefully avoids specifying its use.  I think that this bit of scope-limiting is critical.
 
> It may be worth coding this into the charter as out of scope.

I thought that "Encryption ensures that the proxy is unable to read requests or responses." was pretty clear on this point.  FWIW, I think that the IETF has been pretty good at resisting attempts to remove essential protections in our protocols.  I don't see a need to codify that in a charter; it would say more about our lack of confidence than it would affect outcomes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Mar 2021 15:35:43 -0700

On Thu, Mar 18, 2021 at 12:24:33PM +1100, Martin Thomson wrote:
[...]
> The OHTTP working group will define the Oblivious HTTP protocol, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. The working group will define…

What does it mean to "define an[y] encryption scheme"?

> 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.

Is this intended to be an Applicability Statement as defined in RFC 2026?

> The working group will define a format for any encryption keys that are needed. The working group will not describe how encryption keys are obtained. The working group will not define any methods f…

Why do we need new formats for encryption keys?  Don't we already have a
bunch of those?  Defining how to obtain keys is necessary, of course.

Thanks,

Ben

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 20 Mar 2021 15:58:42 -0700

On Sat, Mar 20, 2021 at 3:35 PM Benjamin Kaduk <[email-masked]> wrote:

> > The OHTTP working group will define the Oblivious HTTP protocol, a
> method of encapsulating HTTP requests and responses that provides
> protected, low-latency exchanges. The working group will define any
> encryption scheme necessary and supporting data formats for carrying
> encapsulated requests and responses, plus any key configuration that might
> be needed to use the protocol.
>

I believe this just means "data format".

> 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.
>
> obtained. The working group will not define any methods for discovering

What you need is actually more like a format for defining the complete
parameter space that the server accepts (key, HPKE algorithm, etc.)
Effectively what's in HPKEConfig:

https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi

-Ekr

> Thanks,
>
> Ben
>
> > The OHTTP working group will work closely with other groups that develop
> the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that
> might use Oblivious HTTP (DPRIVE for DNS over HTTPS).
> >

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 22 Mar 2021 10:32:44 +1100

> I believe this just means "data format".

Correct.  I was just spelling out the crypto piece given how important it is.

> https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi

This is also right.  FWIW, the two documents currently share a common core and I'd like to keep it that way.  I don't think that it makes sense to have one depend on the other from a logistical perspective, but making that small piece of code reusable is worthwhile.

---

From: David Schinazi <[email-masked]>
Date: Wed, 24 Mar 2021 16:52:09 -0700

This draft charter looks good to me, I'd support creation of this WG.

David (no hats)

On Sun, Mar 21, 2021 at 4:34 PM Martin Thomson <[email-masked]> wrote:

> This is also right.  FWIW, the two documents currently share a common core
> and I'd like to keep it that way.  I don't think that it makes sense to
> have one depend on the other from a logistical perspective, but making that
> small piece of code reusable is worthwhile.
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Mar 2021 16:52:59 -0700

As do I.

On Wed, Mar 24, 2021 at 4:52 PM David Schinazi <[email-masked]>
wrote:

>> This is also right.  FWIW, the two documents currently share a common
>> core and I'd like to keep it that way.  I don't think that it makes sense
>> to have one depend on the other from a logistical perspective, but making
>> that small piece of code reusable is worthwhile.
>>

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 30 Mar 2021 09:40:56 -0700

+1 -- thanks for putting this together, Martin!

On Wed, Mar 24, 2021, at 4:52 PM, Eric Rescorla wrote:
> As do I.
> 
> On Wed, Mar 24, 2021 at 4:52 PM David Schinazi <[email-masked]> wrote:
> [email-masked] <mailto:Secdispatch%40ietf.org>