OHAI Minutes @ IETF 117

draft-ietf-ohai-ohttp has completed its second WGLC and is going back to
the IESG.
draft-ietf-ohai-svcb-config is also with the responsible AD (Murray
Kucherawy)
draft-rdb-ohai-feedback-to-proxy: Chairs are planning an adoption call
and are looking to see if there is sufficient interest in the working
group.

Streaming OHTTP (Tommy Pauly)

There is no draft for this concept yet.

Binary HTTP has a mode that omits the length at front, and relies on a
delimiter instead.

For use cases like DNS Tommy is skeptical that streaming is valuable,
but there are other message types that can be processed in multiple
parts.

Jonathan Hoyland: Does this not change the security properties at all?
I'm surprised that security properties are not on the list (on this
slide).
Tommy Pauly: This is documenting the technical, on-the-wire changes that
have to happen. We definitely need to think about the security
properties. For the AEAD, that has been done.
Hoyland: Yes, but does it change the obliviousness?
Pauly: Ah, the privacy aspects. There are two cases: (1) I'm really slow
at sending the response I would have sent anyway. (2) This allows you to
be stateful within that session, in which case the analysis is about the
state that the application is building up within that session. Like if
you flow your whole web browsing session over a single streaming
request, that's clearly bad for privacy.

Ted Hardie: Charter focuses on use cases that do not require correlation
between requests and responses. So you're not going to use this for
Gmail. So if I use OHAI server 1 for request 1 and server 2 for request
2, randomly spread out via ECMP, that's OK. So thank you for the "no",
but I do think it's going to be hard for you to describe in simple terms
(and I encourage you to use very simply terms) which kinds of flows need
this kind of chunked/indeterminate behavior but do not break the
correlation requirement. Also please drop the "streaming" term, as it
suggests a use case that is different from what you have in mind.

Dennis Jackson: The intent here is that the server is going to start
processing before it reaches the end of the stream, or just that the
client can send it a bit at a time?
Pauly: One use case is that you send a small request and get a large
response that takes time to generate. Rather than having to wait for
this whole multi-megabyte response before I can decrypt it, I can start
using it before it's finished.

David Schinazi: In our world where we're working to improve privacy,
OHAI is a good tool, but it's not the only one. We also have MASQUE. I
regularly answer the question "why are we implementing both MASQUE and
OHAI"? I even wrote a draft about this. My answer is if you have
multiple requests are decorrelated, you want OHTTP. If you want them to
be correlated, use MASQUE. So, why can't we just use MASQUE here?
Pauly: There are a couple of other dimensions to why you might choose
OHTTP over MASQUE. OHTTP does require modification by the server,
whereas MASQUE is fantastic for talking to completely unmodified
backends. The other property of OHTTP is the per-message decorrelation
and separation as opposed to per-TLS session.
Richard Barnes: Per HTTP session?
Pauly: Per OHTTP message. So with OHTTP, complete decorrelation is much
more efficient than MASQUE. If the backend is cooperating and you want
this capability, you really want
Schinazi: So with MASQUE you would need a full TLS handshake, whereas
this offers a performance optimization. That makes perfect sense to me.

Pauly: Also, working with cooperating backend servers, forwarding along
a POST request is lighter weight than having to open new TCP addresses
and allocating a client IP address to forward your traffic, etc.

Mark Nottingham: I think Tommy's last comment should go into the OHTTP
draft. What are your intentions about informational/non-final responses?

Pauly: Binary HTTP already handles those and makes it work pretty well.
Actually you kind of need this to make that work. That's actually
another good reason for this.
Nottingham: Sounds good.

Slide 6

I think these are the two primary new requirements. Tell me why I'm
wrong.

Dennis Jackson: This looks right but it's not enough. Without some
additional guidance about where applications cut those chunks, you're
back to the same truncation attack. So for example, if you can add new
content into that stream to move chunk boundaries, which turns out to be
quite common, this can change the recipient's behavior vs. seeing all
that content at the same time.
Pauly: Is that fundamentally different from reading an HTTP/2 stream
that's going to take several minutes.
Jackson: Exactly, but because you have a middle relay, you have an
attacker who is much more capable of interfering with the delivery of
those chunks.
Pauly: Is there anything beyond Privacy+Security Considerations to be
done here?
Jackson: I can't think of anything, but getting that wording correct in
the draft is very important.
Pauly: OK, I'm hearing that we need text about this.
Jackson: And an example of how it can go wrong.

Richard Barnes: Another thing we need is an assurance that all these
chunks end up at the same recipient. OHTTP normally guarantees that the
message arrives at a single server, but that is not necessarily
guaranteed here. Should be mentioned in Operational Considerations.
Pauly: If your chunks are misrouted you will have a very sad day.
Barnes: I've been musing on the question of whether a server is allowed
to respond to the request while it is still arriving.
Pauly: In HTTP it is.
Barnes: Yes, but cryptographically you may need some kind of interlock.

Pauly: I don't believe that is necessary.

Jonathan Hoyland: I do think there's a missing requirement to not allow
insertions. It's trivial but not exactly specified here.

Mirja Kuehlewind: There are applications that can provide bigger or
smaller chunks. So is this the right place to provide this
functionality?
Pauly: Right now, OHTTP only offers exactly one chunk.
Kuehlewind: Yes, but in the application layer I can break my responses
into very small chunks.
Pauly: Right now, I could break the chunks into totally messages, like
separate range requests, but this is simpler.
K: I don't understand the use case well enough to know whether this is
the right solution.

EKR: This sounds like reinventing TLS. The rationale for OHTTP is that
it is simpler. WHy not use MASQUE?
Pauly: YOu missed the earlier discussion. tl;dr TLS requires a lot more
back and forth than chunked OHTTP.
EKR: Yes. Two chunks. Five? Fifty? A million? This seems like recreating
TLS in pieces.
Pauly: Fundamentally, HPKE and OHTTP started by choosing to send one
chunk. I don't see why sending multiple chunks would tell us to change
to a totally new protocol.
EKR: I understand that argument on the margin, but I'm asking you to
look at the general equilibrium, not the margin.
Pauly: Suppose I had a forward proxy, that would require TCP or UDP
forwarding state to the next hop, with IP allocation. This is a lot
easier.
EKR: Yes, that sounds like a sensible argument at the margin, but the
end game is that you've reproduced the TLS protocol. Is this in a -00
draft?
Pauly: Not yet.

Shivan Sahib: Do you have a list of use cases?
Pauly: I've described the properties of the use cases.
Sahib: Yes, but what are they? Do you have a list?
Pauly: I can't get into the details but yes.

Jonathan Hoyland: Can I prove that the entire request before the first
byte of the response has been sent?
Pauly: That is a limitation that you could artificially add, but that is
not a requirement from the protocol or Binary HTTP.
Jonathan Hoyland: So if I were a psychopath, I could send a lot of
requests, get a lot of responses (???)
Hoyland: I think this property is present in the original OHTTP, and I
think we should be careful about losing that property.
Pauly: I think a lot of use cases we have would be fine with that.
Hoyland: Or even just a commitment to the full request in the first
message. What I'm worried about is an adaptive behavior where I change
my request based on the contents of the response.
Pauly: Prohibiting that would make this purely a performance
optimization, which would make it easier to reason about for security
analysis.

David Schinazi: This is an optimization, but it isn't a free
optimization. OHTTP has weaker security properties than TLS or MASQUE.
It has no forward secrecy, whereas end-to-end TLS has perfect forward
secrecy. There are times when it is worth reducing your security for
improved performance, and that is what OHTTP is for. IT makes perfect
sense when you have many independent small messages. But in this case
it's not guaranteed. For a large file download, you are better off using
TLS to get the improved security at a small performance cost. So I would
want to see more analysis of the use case before working on this.

Eric Orth: I think any draft on this should recommend using TLS "if this
is true". Then we can try to figure out where these borders are on
whether to use OHTTP vs. TLS. We need to figure that out before we can
have a reasonable draft.

EKR: One of the advantages of transport is that there's no obvious way
to make rate control work. There's rate control on each link but it's
extremely goofy.
Pauly: Any relay is responsible for propagating backpressure, which is
also true for any reverse proxy.
EKR: This is why we want to run QUIC over MASQUE instead of TCP, because
it gives us rate control end-to-end.
Pauly: A large OHTTP relay is going to have a single session with each
gateway, rather than a ton of separate connections. So it is better for
performance.
EKR: WHy is that better?
Pauly: In the case of MASQUE, what we want ultimately is this end-to-end
session for HTTP/3 or HTTP/2 to the end server. In this case, the client
has a session to the relay, which has one large logical session to the
gateway.
EKR: I'm saying that's a defect. You have totally decoupled rate control
between the data in each direction, and it's weird.
Richard Barnes: Are you thinking about cases where there is no
backpressure and a buffer builds up?
EKR: We're removing automatic backpressure from the transport protocol,
and replacing it with backpressure at the application layer.
Pauly: This is pretty well-established for HTTP request-response.
EKR: Yes, but they're self-clocking because they're one-to-one. This may
require an offline discussion. It's one thing to say "I want to send two
chunks", but when it's I want to send a giant stream, it's a different
story.
Pauly: I think the question is really: there's a large response. Am I
waiting for that or not?
EKR: As David indicated, the price you paid for this is forward secrecy.
But there's a bigger price: it doesn't work with unmodified servers.
Pauly: Yes, but the server is participating to support improved
decoupling.
EKR: The reason that tradeoff made sense is because you were only
suggesting one message.
Pauly: We're considering a use case where the response is often a single
chunk, but sometimes very large and benefits from streaming.
EKR: I'm waiting to hear about that use case. This is not the web. The
endpoints are controlled by both sides, so you probably have some
intelligence about what the response is likely to be.

Slide 7-8

Proposed protocol is borrowed from Martin Thomson's Github PR last year.

Slide 9

Maybe this could be called "chunked" instead of "streamed".

Slide 10

Mark Nottinham brought up these points.

I'm not sure how we would discover this. Generally there is some amount
of prior configuration of the gateway, so I'm not aware of a case where
discovery is required.

END SLIDES

Ben Schwartz: Can we rotate keys more frequently to restore forward
secrecy?
Pauly: Key distribution is not specified in OHTTP, so we don't have a
way to specify doing it faster.
Schwartz: Maybe a BCP would help people feel more confident that this is
going to be deployed in a way that has a good security properties.

Jonathan Hoyland: You could put pre-keys in DNS and change them every
request.
Pauly: I'm concerned about targeting in that case.
Barnes: Let's not reinvent MLS.

Schinazi: Another security property that this lacks is replay
protection. The draft says this, but it's not marketed very well. It's
easy to forget. This sounds like it's building something that has these
weaker properties that people might use inappropriately. Also, the
security properties look a lot like 0-RTT, in fact it's the same
constructing as gQUIC 0-RTT. And Ben's proposal to inject a new key is
exactly how gQUIC transitioned to 1-RTT. Overall, this sounds like
reinventing TLS but only 0-RTT. So we should have a longer discussion
about security and make sure we're not making something that is going to
be used inappropriately, like for large file downloads.
Pauly: This validates our decision not to start with streaming in the
original draft of OHTTP.