Re: FYI: Oblivious HTTP

[Toerless Eckert <[e-mail]>]

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

On Thu, Jan 28, 2021 at 12:27:38PM +1100, Martin Thomson wrote:
> 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/

-- 
---
[e-mail]