The protocol was briefly described. New length field, media types.
Issue #5: Negotiating use
Tommy: Out of band vs OHTTP key config in some way vs optimistic try it?
Apple's existing use makes use of out-of-band config most of the time.
Jana: is this a general discovery problem? Agree it's good to be
consistent.
Martin: Just trying it isn't necessarily a bad approach.
Tommy: If we just try it, it may not be consistent. Could vary with
time. Gateway and relay likely have some relationship established.
Jana: Gateway and relay don't necessarily have a relationship. Useful to
announce this directly.
Tommy: The gateway doesn't need to know about every relay. The relay
needs some preconfiguration about gateways.
Rich: Chunked keys same as normal keys? Wouldn't a non-chunked response
to a chunked request signal non-support?
Tommy: I'm expecting that.
Mark: Recommend media type, plus whatever. Can always supplement it
later.
Tommy: Signaling chunking support for some requests but not others could
leak information.
Issue #7: Maximum chunk sizes
Tommy: Should they be restricted? Leaning towards no.
Martin: 2^62 would be bad for a memory request. Advisable to specify
something, for interoperability. We need to pick a size (a power of 2).
Jana: Not a power of 2
Lucas: Related work on upload sizes. Each proxy might have its own
limit. Per-resource limits. We could put this in a header with a fixed
value.
Kyle: Important we have a maximum. Will vary between use cases.
Richard: MLS limits size of varints, although they're still pretty big.
David: 1GB?
Jana: Is this needed for interoperability or not?
Rich: Would be good to have a fixed upper limit. Don't encode it in the
protocol.
Tommy: So we could pick our favorite.
Next steps
Adding formal analysis, test vectors, and expand privacy discussion.
Linmao: Use case is for DAP clients to communicate to DAP leader, via
OHTTP. Concerned with correlation & ordering attacks. Mitigation is
batching and shuffling between OHTTP Relay and OHTTP Gateway. Want to
know if WG considers this a reasonable use case, and if the extension is
the right approach.
Ben: This came up in context of DSS*. What is motivating this attack?
Linmao: Main concern is an observer of the traffic.
Ben: Observer could see the batching and infer that the user is a member
of a batch.
Linmao: Shuffling, grouping and batching seems to be a potential way to
limit the issue.
Martin: Split. It's just using an existing HTTP status code. Store and
forward for HTTP requests is a new thing. Need to think about the
consequences of that. It has implications for reliability and server
infrastructure.
Richard: Relays are already doing this.
Martin: If we build this mechanism it will be generic.
Richard: Any opposition to adoption?
Mark: Concerned about changing the footprint of HTTP and need to have
that discussion. Every time you change HTTP you need to think about all
the components this will affect.
Tommy: Agree. The draft is one way to do this. Ask ourselves is this a
problem worth solving? There are privacy benefits. Can we do this in a
way that is limited to existing semantics? Or narrow scope to avoid it
being used generically?
Martin: Definition of 202 invites this interpretation. But not well
used. There might be gotchas.
Richard: Is it important for client to get ?
Tommy: We don't need anything that says "I'm going to batch this". We
can expect that the relay knows that it will act in this way, out of
band. The relay can know that for this gateway it will always get a 202.
Mark: The relay is an HTTP resource. Changing expectations.