Subject: FYI: Oblivious HTTP

From: "Martin Thomson" <[email-masked]>
Date: Thu, 28 Jan 2021 12:27:38 +1100

Just an announcement for a new draft that proposes a use of HTTP that this group might be interested in.  I've started a discussion on the SECDISPATCH list about it [1].  Please, if you are interested in this topic, join that conversation.

The draft:

https://www.ietf.org/archive/id/draft-thomson-http-oblivious-00.html

What this group might be more interested in is whether the ecosystem is well-served by a binary message format.  That work currently has a dependency on another proposal:

https://www.ietf.org/archive/id/draft-thomson-http-binary-message-00.html

It doesn't strictly need to take this dependency, as message/http is in some ways adequate.  However, I think that it might be beneficial to have a discussion about this idea here.

Cheers,
Martin

[1] https://mailarchive.ietf.org/arch/msg/secdispatch/VmFQCZGKlukgfnmgPh8ufQt_5Fo/

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Jan 2021 18:19:58 +1300

> https://www.ietf.org/archive/id/draft-thomson-http-oblivious-00.html

Looks to me like it should obsolete or at least deprecate RFC 2660.

AYJ

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 28 Jan 2021 20:07:44 +1100

> Looks to me like it should obsolete or at least deprecate RFC 2660.

Interesting comment.  I never thought of RFC 2660 as other than an exercise in documenting a failed experiment.

That said, you are right to point to the similarities.  It does share some of the characteristics of the SHTTP design, but only superficially.  It is also very different in enough ways that I wouldn't have thought to consider this as a replacement or successor.  I don't think that a reference to RFC 2660 is needed.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 28 Jan 2021 18:54:53 +0100

Hi Martin

Thanks for the work. Very interesting.

Some questions/concerns/suggestions:

a) "oblivious" (non-technical comment)

a.1) I can not find text in the document that motivates the choice of the
name 'oblivious' for this mechanism.

Who/what is exactly oblivious of what in this solution ? I guess that
the network to the right of the proxy resource (in figure 1), including
the target resource is "forced to be 'oblivious' of the client network layer identity" ?

Aka: add explicit text explaining the exact semantic of 'oblivious' in the
context of this doc.

a.2)  I fear the word oblivious does not even well characterize the
core value proposition of this mechanism:

Any existing (thor,...) solution would be quite similarily providing
"obliviousness" in this sense, so 'oblivious' is not rally the unique
new value proposition. And every existing network/http-server that
does not examine the client network-layer identity is already oblivious
of it as well. 

Secure and initiator-identity opaque (HTTP) transaction routing  ? 

Yeah, "oblivious" sounds a lot cooler, just not logical...

b) Performance (non-technical comment)

The real value proposition seems to be performance of what i would describe
as HTTP transaction routing in this solution vs. single-transaction
connection setup through proxies. Correct ?

It would be great to have a persuasive example quantified comparison in the
text in terms of likely difference in performance. For example number of
messages/roundtrips crypto oprations, amount of state in proxy, etc. pp.
(this mechanism vs. a TLS setup).

Also of course and i think quite importantly: How big would the difference
still be if HTTPs (with TLS) was replaced by QUIC - which i think values itself
for minimizing rtts/messages.

c) Figure 1 (minor):

Is it possible to have two or more proxy resources ? I assume
it is, but it would be very good to make this explicit in the picture
by visualizing e.g.: 2 of them and saying "one or more" in the text.

d) Generationalization (technical comment)

It seems to me as if the mechanism at its core is really a new brand
of transaction routing based on URL for rquest and HPKE context for reply
if i understand right. I wonder why this is being defined only for HTTP.

Would it not be more easily reuseable across a lot of different transaction
protocols if it came with its own message type header and a demux for the
transaction protocol ? Might be possible then to support HTTP, CoAP, MQTT
and what else theree might be flying around (especially in the IoT world)
with a single mechanism, and avoiding a lot of duplicate specs. Or even if 
starting with HTTP maybe at least look for easy extension points and avoiding 
any unnecessary HTTP overhead/complexities if the messages routed are not
HTTP but from an extension point...

In fact (IMHO), the value of this mechanism is likely going to be higher for
higher layer transaction systems built from the ground up and not
encumbered in all the entrenched tracking mechanisms we have in HTML/"Web-Apps"
these days, so offering extension points to leverage the infrastructure
for new, less intrusive higher layers might be quite beneficial to the success
of this mechanism.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 28 Jan 2021 12:15:18 -0800

> On Jan 27, 2021, at 5:27 PM, Martin Thomson <[email-masked]> wrote:
> 

Personally, I think we have passed the inflection point where anonymous use
of the Internet is an ideal, and we are quickly heading back to a world where
accountability for its misuse is just as important. But that's a digression.

Technically, I don't feel that wrapping base HTTP semantics as an encrypted
package containing a binary encoding of HTTP/1, and then using POST to fling
it around the world, is the right approach. I could understand that if the primary
motivation was to pass through client-selected proxies without using TLS,
or if the client engine was limited to javascript on a page, but not if we assume
the client is deliberately coding for this protocol and servers are deliberately
willing to accept such requests. POST is significantly harder to process than
it looks.

I suggest that it would be better to design a protocol that accomplishes exactly
what you want in the most efficient way possible and find ways to blend that
with the existing HTTPs. For example, using non-https link alternatives and
Alt-Svc to identify oblivious resources. Using QUIC datagrams for sending
opaque requests (I don't see a need to send these as HTTP/3) and receiving
opaque responses. Mapping to other protocols only as a way of supporting
backwards deployment over those old protocols.

OTOH, oblivious connections will mislead if there are no equivalent constraints
on what the client can do/enable with the content received. Almost all tracking
today is done based on client behavior after receipt of the primary resource,
including what is executed within the page, how the page components are
ordered, what needs to be refreshed, links to other pages, what servers
might share the same TLS certificate, etc. Relying on clients to restrain
themselves doesn't work in practice, even though it should work in theory.

As such, I think systems like TOR that are built on trust and actively mediate
and adapt to changing malpractice is a better solution. But don't let that stop you
from designing something better.

....Roy

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Jan 2021 09:38:19 +1100

Thanks Toerless,

Brief responses only.

> a) "oblivious" (non-technical comment)

The choice of naming is a nod of acknowledgment to the original work <https://dl.acm.org/doi/abs/10.1145/3340301.3341128>.  It's not perfect, but it is also fairly well understood what it means in context even if that doesn't correspond very well with the English definition.

> connection setup through proxies. Correct ?

Yes.  The key observation here is that achieving these privacy properties can be made faster than making a fresh, proxied  connection for every request.  If you are looking for an idea of the performance, Cloudflare did some research on a very similar mechanism: <https://blog.cloudflare.com/oblivious-dns/>

> for minimizing rtts/messages.

QUIC is better than TCP (which is why it exists), but the crypto costs are the same and it can't do this without adding round trips.
 
> Is it possible to have two or more proxy resources ? 

Yes, this can be applied iteratively.  If you like, you could re-build something akin to Tor based on the underlying mechanisms, but that requires a whole lot more stuff than this.  It would also throw up a whole bunch of new problems.  I'll leave that to others to contemplate.

> if i understand right. I wonder why this is being defined only for HTTP.

Nothing wrong with using this template to build a similar mechanism for another protocol, but I don't believe that there is value in taking generalization that far.  It shouldn't be hard to write an adaptation to Diameter or whatever protocol you had in mind if that is your inclination.  But that would require use cases that depended on those protocols and I am not in a position to know whether those use cases exist.  I can only say that I have a use case that would benefit from carrying HTTP exchanges.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Jan 2021 11:19:59 +1100

Thanks for the thoughtful response Roy.

> accountability for its misuse is just as important. But that's a digression.

I would love to indulge this digression, because I'm forced to agree that lack of accountability is one of the things that has contributed to the current messy situation.  But it's a difficult conversation and I don't know that we're properly equipped for that discussion here.  I wish we were, because while we might not be entirely responsible for the situation, it is not like we haven't made contributions and we probably have resources that might be turned to helping, if only we knew how.
 
> backwards deployment over those old protocols.

I don't think that attempting to define a new protocol for this is a good idea.  This is a protocol with niche applicability (I'll get back to this in a bit), so reuse is most appropriate.  And we need a protocol that supports reliable, in-order delivery of units that might exceed an MTU in size.  We need a protocol that is able to support request/response exchanges.  Ideally, we have a protocol that doesn't assume transfer of state between exchanges (for the proxy to request/target interaction only).  Ideally, we have a protocol that can amortize setup costs well.

HTTP does all of that.  It does a lot more than that, but none of the extra things HTTP provides are an obvious impediment to its use, and many could be valuable.  It also enjoys wide deployment, diverse and robust implementation support, interoperability, and a bunch of other advantageous things.

I certainly agree that slinging around encrypted blobs in POST isn't making the best use of the protocol.  But I'm not aware of any alternative option that is even comparable on any metric that matters.  The original oblivious DNS design used the DNS protocol, and the extent to which that required compromise to even get it to work was pretty bad.  As much as I love designing new protocols, this doesn't seem to be the right opportunity.

> from designing something better.

I think that it might be best to respond with a little more context on what I believe the potential application of oblivious HTTP would be.  The draft doesn't really go into that, because that isn't really a good place to capture these sorts of things.

Just to set this aside, I don't see this as building toward replicating something like Tor.  There are obvious parallels, but the two approaches have very different assumptions about trust and the incentives of various actors.  Tor, as a system, is also far more complex and ambitious.  So, by all means look for parallels in Tor, but understand that this has very different models for both the threats it considers and the environment it might be deployed in.

The other thing that I think is important to understand is that - at least from my perspective - the goal is not to carry any significant proportion of HTTP requests.  For instance, I don't see this being used for web browsing.  If we're willing to echo cookies, then you can safely assume that we won't be making those requests oblivious.  And many other cases benefit from being able to establish some sort of continuity, if only to deal with denial of service risks.  Each application would have to be assessed on its own.

The things that we're talking about using this are those cases where we have identified a privacy risk associated with having a server being able to link requests.  The original case in research was DNS queries, where it has been shown that building profiles of users based on their DNS activity has poor privacy properties.  At Mozilla, we're also considering this style of approach in other places that browsers make requests with information that might be sensitive, like telemetry reporting.

There are non-trivial costs associated with setting this up.  As a proxy needs to be run by a separate entity, but they don't see any direct benefit from the service they provide, you have to arrange for their costs to be met somehow.  You need to do so in a way that the server can ensure that the proxy is not enabling DoS attacks, while also retaining sufficient independence that clients can trust the proxy.  This is harder as the use cases become more general, but we believe that this can be arranged for certain specific cases.

Does the explanation about applicability help?  I realize now that I shouldn't have left this up to inference, and the draft should probably at least address the point directly, so I'll make sure that the next version does something about that.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 29 Jan 2021 08:22:23 +0000

--------
Roy T. Fielding writes:

> it around the world, is the right approach.

As a general rule:  Political problems do not have technical
solutions, and if the past couple of decades are any guidance,
attempting to 'lock in' politically unsettled human rights with
cryptography only seems to make matters worse.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 29 Jan 2021 13:05:16 +0100

On Fri, 29 Jan 2021 at 09:25, Poul-Henning Kamp <[email-masked]> wrote:

> solutions,...

True, but political movements have often made maximum usage of the
technological tools made available to them.
So as much as it is valid to work on technology for anonymity and
confidentiality, we as a community should also make sure that  there are
equally good solutions for accountability and integrity.

-- 
Greg Wilkins <[email-masked]> CTO http://webtide.com

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 29 Jan 2021 13:57:41 +0100

> The choice of naming is a nod of acknowledgment to the original work <https://dl.acm.org/doi/abs/10.1145/3340301.3341128>.  It's not perfect, but it is also fairly well understood what it means in…

Sure. write that into the intro of your doc to motivate the choice of name.

> Yes.  The key observation here is that achieving these privacy properties can be made faster than making a fresh, proxied  connection for every request.  If you are looking for an idea of the perfo…

Add as reference.

> QUIC is better than TCP (which is why it exists), but the crypto costs are the same and it can't do this without adding round trips.

Some summary of example performance comparison of the proposed mechanism
vs. those alternatives in the document itself will be appreciated. I for
once can probably figure  out myself the difference in packet/rtt overhead
but i am less knowledgabe about the crypto difference.

> Yes, this can be applied iteratively.  If you like, you could re-build something akin to Tor based on the underlying mechanisms, but that requires a whole lot more stuff than this.  It would also t…

Hmm. Are there fundamental additional complexities doing multiple
proxy hops in your mechanism vs. those in Thor ? Would be good
to understand/document in the draft anything novel, even if its not positive...

> Nothing wrong with using this template to build a similar mechanism for another protocol, but I don't believe that there is value in taking generalization that far.  It shouldn't be hard to write a…

Definitely required to show use-cases before thinking about codying anything
more generic. I was just trying to understand better what is and what is
not HTTP specific in the proposal. Somewhat hard to figure out from the
text now.

Thanks for explaining!

Cheers
    Toerless

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 29 Jan 2021 11:48:29 -0800

> On Jan 28, 2021, at 4:19 PM, Martin Thomson <[email-masked]> wrote:
> 

Yes, that helps. I guess my big question is whether the proxy is aware of "for whom" (in an account sense) the proxy is doing this work (unlinkable requests), or does the scope require that the proxy be oblivious to both what is being requested and who is doing the requesting?

....Roy

---

From: David Benjamin <[email-masked]>
Date: Fri, 29 Jan 2021 20:08:19 -0500

On Thu, Jan 28, 2021 at 7:23 PM Martin Thomson <[email-masked]> wrote:

> I think that it might be best to respond with a little more context on
> what I believe the potential application of oblivious HTTP would be.  The
> draft doesn't really go into that, because that isn't really a good place
> to capture these sorts of things.
>
> Just to set this aside, I don't see this as building toward replicating
> something like Tor.  There are obvious parallels, but the two approaches
> have very different assumptions about trust and the incentives of various
> actors.  Tor, as a system, is also far more complex and ambitious.  So, by
> all means look for parallels in Tor, but understand that this has very
> different models for both the threats it considers and the environment it
> might be deployed in.
>
> The other thing that I think is important to understand is that - at least
> from my perspective - the goal is not to carry any significant proportion
> of HTTP requests.  For instance, I don't see this being used for web
> browsing.  If we're willing to echo cookies, then you can safely assume
> that we won't be making those requests oblivious.  And many other cases
> benefit from being able to establish some sort of continuity, if only to
> deal with denial of service risks.  Each application would have to be
> assessed on its own.
>
> The things that we're talking about using this are those cases where we
> have identified a privacy risk associated with having a server being able
> to link requests.  The original case in research was DNS queries, where it
> has been shown that building profiles of users based on their DNS activity
> has poor privacy properties.  At Mozilla, we're also considering this style
> of approach in other places that browsers make requests with information
> that might be sensitive, like telemetry reporting.
>
> There are non-trivial costs associated with setting this up.  As a proxy
> needs to be run by a separate entity, but they don't see any direct benefit
> from the service they provide, you have to arrange for their costs to be
> met somehow.  You need to do so in a way that the server can ensure that
> the proxy is not enabling DoS attacks, while also retaining sufficient
> independence that clients can trust the proxy.  This is harder as the use
> cases become more general, but we believe that this can be arranged for
> certain specific cases.
>
> Does the explanation about applicability help?  I realize now that I
> shouldn't have left this up to inference, and the draft should probably at
> least address the point directly, so I'll make sure that the next version
> does something about that.
>

I agree the draft should talk about this. I initially read it as intending
a general replacement for proxying strategies, which seemed odd. As you
note, in more stateful contexts like web browsing, the correlation
boundaries are so much larger than a request that this probably doesn't buy
much over simply partitioning connection pools. Whereas I could see
applications with more standalone requests wanting different tradeoffs.

One comment on the privacy properties here: the requests are only as
uncorrelated as the key configurations used by the client. In the online
HTTPS fetch model described here, if each client independently fetches, the
server could maintain many configs and serve a different one each time. I
assume that the client will cache the key configuration (otherwise it needs
a new fetch per request, at which point it may as well just tunnel HTTPS),
which means clients can be identified, or partially identified by their
keys. This is helped a bit by the small keyID size: the server gets 8 bits
plus a couple more from algorithm selections, and then the rest must come
from trial decryption. But how well this mitigates it depends on volume and
whether this could be combined with information in the requests themselves.
(E.g. telemetry reports may reveal platform information or rough
performance characteristics.) That's probably worth some text, both on the
privacy implications of the suggested configuration model, and on privacy
implications of configuration models in general.

Alternatively, the proxy could cache and serve the key configuration. Then
everyone behind the same proxy uses the same config. Though you'd then need
some kind of offline authentication on the config, such as SXGs.

I think the draft should also discuss the security implications a bit more,
since it's replacing the guarantees you'd otherwise get from proxying
HTTPS. Some things that came to mind:

- Related to all the online vs offline signature excitement, the client
probably needs to enforce a time bound on key configurations, in order to
contain the effects of a temporary compromise.

- Like TLS 1.3 0-RTT, encapsulated requests don't have replay protections
and lack forward secrecy. This shouldn't be used where replay protection
matters, and key configurations should be rotated frequently.

- Unlike TLS 1.3 0-RTT, encapsulated responses also lack forward secrecy.
(If it's an issue, I suppose you could fix this by doing a second HPKE in
the other direction and binding the two together.)

David

---

From: "Soni L." <[email-masked]>
Date: Sat, 30 Jan 2021 08:48:38 -0300

> Does the explanation about applicability help?  I realize now that I shouldn't have left this up to inference, and the draft should probably at least address the point directly, so I'll make sure t…

While I understand this is intended for use with DNS, I can't help but 
notice some parallels between this and a previous proposal of mine, 
https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0164.html

Simply encrypting the requests through a single common proxy isn't gonna 
prevent the server from identifying the user. Even worse - it 
additionally lets the common proxy identify the user. You *need* 
multiple independent proxies.

The main difference between this proposal and my previous proposal 
however, is that this attempts to prevent correlation of requests by the 
server, whereas my proposal attempts to prevent correlation by the 
proxy. Also, one major flaw with my proposal is the possibility of the 
CDN/proxy hijacking the nested TLS by making its own certs through 
something like Let's Encrypt, by pretending to be a plain HTTP/S server, 
whereas this seems to be about user-selected proxies.

Have I understood these correctly?

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jan 2021 16:42:27 -0800

On Fri, Jan 29, 2021 at 5:11 PM David Benjamin <[email-masked]>
wrote:

>> The other thing that I think is important to understand is that - at
>> least from my perspective - the goal is not to carry any significant
>> proportion of HTTP requests.  For instance, I don't see this being used for
>> web browsing.  If we're willing to echo cookies, then you can safely assume
> uncorrelated as the key configurations used by the client.
>

Yes. This is like PrivacyPass in that respect.

In the online HTTPS fetch model described here, if each client
> independently fetches, the server could maintain many configs and serve a
> different one each time. I assume that the client will cache the key
> configuration (otherwise it needs a new fetch per request, at which point
> it may as well just tunnel HTTPS), which means clients can be identified,
> or partially identified by their keys. This is helped a bit by the small
> keyID size: the server gets 8 bits plus a couple more from algorithm
> selections, and then the rest must come from trial decryption. But how well
> this mitigates it depends on volume and whether this could be combined with
> information in the requests themselves. (E.g. telemetry reports may reveal
> platform information or rough performance characteristics.) That's probably
> worth some text, both on the privacy implications of the suggested
> configuration model, and on privacy implications of configuration models in
> general.
>

It's worth noting that in a number of these cases (e.g., Telemetry) you'll
want to preconfigure the key into the client, in which case this becomes
less of an issue.

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Feb 2021 10:29:38 +1100

On Sat, Jan 30, 2021, at 06:48, Roy T. Fielding wrote:
> Yes, that helps. I guess my big question is whether the proxy is aware 
> of "for whom" (in an account sense) the proxy is doing this work 
> (unlinkable requests), or does the scope require that the proxy be 
> oblivious to both what is being requested and who is doing the 
> requesting?

In the cases that we are looking at, the proxy is entirely aware of the type of data that is passing.  Let's say that we use it for DNS resolution.  In theory, a builder of a client X (who makes the requests) might arrange with Y (as provider of a proxy) and Z (as provider of a DNS resolver).  X and Z agree that the data is worth protecting and mutually agree to ask Y help them protect it.  Y almost certainly knows that this is DNS queries, and might even insist on the use being limited to that.

What is not visible here is the correlation between individual client instances and the queries they make.  That would require cooperation between Y and Z.  And X trusts Y not to allow that.  X might even insist on contractual terms.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Feb 2021 11:29:09 +1100

Thanks David, these are all good points to capture.  I've flagged you on the issues I've created in response to these; though it will take a little bit of work to get this all written down.

For those following along at home: https://github.com/unicorn-wg/oblivious-http/issues

On Sat, Jan 30, 2021, at 12:08, David Benjamin wrote:
> I agree the draft should talk about this. I initially read it as 
> intending a general replacement for proxying strategies, which seemed 
> odd. As you note, in more stateful contexts like web browsing, the 
> correlation boundaries are so much larger than a request that this 
> probably doesn't buy much over simply partitioning connection pools. 
> Whereas I could see applications with more standalone requests wanting 
> different tradeoffs.
> 
> uncorrelated as the key configurations used by the client. In the 
> online HTTPS fetch model described here, if each client independently 
> fetches, the server could maintain many configs and serve a different 
> one each time. I assume that the client will cache the key 
> configuration (otherwise it needs a new fetch per request, at which 
> point it may as well just tunnel HTTPS), which means clients can be 
> identified, or partially identified by their keys. This is helped a bit 
> by the small keyID size: the server gets 8 bits plus a couple more from 
> algorithm selections, and then the rest must come from trial 
> decryption. But how well this mitigates it depends on volume and 
> whether this could be combined with information in the requests 
> themselves. (E.g. telemetry reports may reveal platform information or 
> rough performance characteristics.) That's probably worth some text, 
> both on the privacy implications of the suggested configuration model, 
> and on privacy implications of configuration models in general.
> 
> Alternatively, the proxy could cache and serve the key configuration. 
> Then everyone behind the same proxy uses the same config. Though you'd 
> then need some kind of offline authentication on the config, such as 
> SXGs.
> 
> I think the draft should also discuss the security implications a bit 
> more, since it's replacing the guarantees you'd otherwise get from 
> proxying HTTPS. Some things that came to mind:
> 
> probably needs to enforce a time bound on key configurations, in order 
> to contain the effects of a temporary compromise.
> 
> - Like TLS 1.3 0-RTT, encapsulated requests don't have replay 
> protections and lack forward secrecy. This shouldn't be used where 
> replay protection matters, and key configurations should be rotated 
> frequently.
> 
> - Unlike TLS 1.3 0-RTT, encapsulated responses also lack forward 
> secrecy. (If it's an issue, I suppose you could fix this by doing a 
> second HPKE in the other direction and binding the two together.)
> 
> David