Draft: draft-thomson-http-oblivious

Commentary: I 've also taken the time to review the text in the ( now ) security considerations and expand on some of the responsibilities . Including the one where the client needs to authenticate key configurations . 
 And document the requirements for this format ( namely that it be authenticated and attributed to the oblivious request resource ) . 
 Right now we just use words for this , but we might want to define a format that includes  , KEM , KDF , AEAD , and pk for the server . A media type for this might be good . Given the general applicability of this , it might want to be a separate document . 
 I would suggest we steal either the MLS or the ECH format . 
 That seems ideal . I was more thinking about how we might represent this information as a media type or in a header field . Right now , we 're assuming configuration rather than discovery , but for things like key rotation , it could be helpful to include a way to provide updated keys . One way this might help to provide a way for an oblivious request resource to indicate some of the keys that can be used to talk to it . 
 I looked at the ECH format and it was n't suitable . It does n't include a key identifier ( it uses that hashing thing for identification ) and it relies on TLS signaling the KDF and AEAD that was chosen . It also includes stuff we do n't need . The MLS  is even more divergent from our needs . MLS remaps the KEM , KDF , and AEAD identifiers and includes a bunch of other stuff we do n't need . What I 've implemented , which can easily change is this : However , I think that it makes sense to have a format that wraps multiple keys , say : This would allow an oblivious request resource to advertise multiple keys . Drawbacks : This is not space efficient : if the same key supports multiple configurations , then this will require that the key be repeated multiple times , and with a different key identifier for each . But I 'm going to suggest that gzip can solve that problem for us . There is no way to annotate individual keys . This might complicate the addition of per - key expiration times . My initial view is that once replacement keys are available , you do n't need to advertise other keys , even if you still accept requests for some time . All told , this is starting to smell like a substantial enough piece to warrant a separate document . 
  ... I 'm not sure I agree with this analysis . This seems to me that it 's isomorphic to the ECH situation , you 're just making a different design tradeoff about where to carry the KDF and AEAD , for instance . What stops you from using the hashing thing and carrying the KDF and AEAD in this brand new format ? 
 OK , I 'm going to try not to react here with how abhorrent the hashing thing is , but I think that it exists primarily to avoid carrying information in the ECH context . We could carry certainly carry KDF and AEAD identifiers separate to the key identifier . That 's a choice that would allow us to reuse the part of the ECH configuration that repeats that piece . And have multiple combinations of those for the same key identifier . I do n't care so much about that piece , though in practice you can get that by packing those fields into the key identifier . The pieces we really do n't want are the public name ( which means nothing in this context ) and extensions . This is not something that needs extending arbitrarily . 
 My point is that the design considerations are no different here than for ECH . As far as I can tell , this simply reflects a different aesthetic preference . That 's fine , but I think consistency of design is useful and important , and so to the extent to which it 's just aesthetics we should come down to one conclusion and then impose it on both . If that means changing ECH , then so be it . I agree with this . I do n't agree with this . My experience is that more or less whenever we make the decision not to leave ourselves extension points we find that we regret this . In that vein , it 's worth noting that we can address the public name issue by making public name an extension , thus harmonizing the formats and avoiding the clutter here . 
 I value reuse , but not to that extent . Not when it means a format that has extensions , where in one context extension A is mandatory , but in another context extension B is mandatory instead . And all the mess that comes with extension processing to boot . 
 Oh , and this point : I would expect to be able to use a different extension point at the next layer up . That is , define a new media type or whatever . 
 For what it 's worth , I would like for ECH and OHTTP to share the same shape of configuration , modulo the unnecessary bits ( public name ) . can you elaborate on why the client - computed Key ID is , well , abhorrent ? :-) 
 While I do n't agree with MT about extensions , perhaps we could factor out the common pieces into a component that could be used by both ECH and OHTTP could use -- and maybe even MLS . 
 So , a server - chosen key ID does seem attractive , for a number of reasons : Deployment - specific flexibility in the ID -key mapping Avoids hash computation ( and algorithm choice ) on clients However , for the sake of exploration , let 's say a server wants to publish two configs -- one for AES and another for ChaCha . Clients would obtain this set of of configs ... somehow ... and make a choice between the two based on their preferences ( do they support AES intrinsics ? ) . Let 's say an attacker stripped the config with AES from the response to client , forcing it to use ChaCha . The client 's Key ID signal does not indicate to the server that the chosen key was made from an incomplete view of the keys . Is this a problem ? Perhaps not for AEAD algorithms we care about , but what about in a future world where one key carries a PQ KEM public key and another carries a classical KEM public key ? If we think KEM key selection is a problem , then it seems there are a couple ways to address this : clients signal to servers their view of the config set ( as is done in ECH with the config_id being computed as a hash of the ECHConfig ) attackers ca n't interfere with client view of configs If OHTTP configs are published in DNS ( I 'm not necessarily advocating for this ) , then ( 1 ) seems preferable . If OHTTP configs are fetched directly from the request resource , then perhaps ( 2 ) applies ? I guess the representation of the key ID depends on the threat model , which is n't surprising . :-) what do you think ? 
 I spent some time looking back at the history of ECH . It turns out that I originally had a key i d and then  proposed removing it , mostly on the grounds that it was easier to manage with a unique value . It seems like the situation is basically the same here for O - HTTP as for ECH , so we should converge on a common answer whatever that is . WRT the question of negotiation , ISTM that that 's a function of folding the entire configuration into the transcript , and so obviously another identifier is needed if you want to refer to a specific component in the configuration , whether that 's a key or a config instance or whatever . 
 To clarify , are you suggesting possibly folding the entire config set into the transcript and then identifying one specific config in that set ( via key i d ) ? 
 If you 're concerned about downgrade , I think it 's the only way . Though of course at that point the client has already sent the information , so the value is limited . 
 Yeah , that 's a good point . So perhaps there 's not much we can do about downgrade other than ensure integrity for the config set ? 
 Documented the agreed format in . We 've still open questions about the extent to which this and ECH can be harmonized , so I 'll open a separate issue to ensure that happens . 
 Let 's leave as where we can track key format changes .
Though this scheme requires that servers and proxies explicitly
support it, this design represents a performance improvement over
options that perform just one request in each connection.  With
limited trust placed in the proxy (see trust), clients are assured
that requests are not uniquely attributed to them or linked to other
requests.
Though this scheme requires that servers and proxies explicitly
support it, this design represents a performance improvement over
options that perform just one request in each connection.  With
limited trust placed in the proxy (see security), clients are assured
that requests are not uniquely attributed to them or linked to other
requests.
A client needs to acquire information about the key configuration of
the oblivious request resource in order to send encapsulated
requests.
In order to ensure that clients do not encapsulate messages that
other entities can intercept, the key configuration MUST be
authenticated and have integrity protection.  One way to ensure
integrity for key configuration is for the oblivious request resource
to serve content to the client directly, using HTTPS and the
"application/ohttp-keys" media type; see ohttp-keys.
Specifying a format for expressing the information a client needs to
construct an encapsulated request ensures that different client
implementations can be configured in the same way.  This also enables
advertising key configurations in a consistent format.
A client might have multiple key configurations to select from when
encapsulating a request.  Clients are responsible for selecting a
preferred key configuration from those it supports.  Clients need to
consider both the key encapsulation method (KEM) and the combinations
of key derivation function (KDF) and authenticated encryption with
associated data (AEAD) in this decision.
Evolution of the key configuration format is supported through the
definition of new formats that are identified by new media types.
A single key configuration consists of a key identifier, a public
key, an identifier for the KEM that the public key uses, and a set
HPKE symmetric algorithms.  Each symmetric algorithm consists of an
identifier for a KDF and an identifier for an AEAD.
format-key-config shows a single key configuration, KeyConfig, that
is expressed using the TLS syntax; see Section 3 of TLS.
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF,
and AEAD respectively.  The definitions for these identifiers and the
semantics of the algorithms they identify can be found in HPKE.
The "application/ohttp-keys" format is a media type that identifies a
serialized collection of key configurations.  The content of this
media type comprises one or more key configuration encodings (see
key-config) that are concatenated.
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
Clients MAY include fields that do not reveal information about the
content of the request, such as Alt-Used ALT-SVC.
A client interacts with the oblivious proxy resource by constructing
an encapsulated request.  This encapsulated request is included as
the content of a POST request to the oblivious proxy resource.  This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(media-types), and the encapsulated request as the request content.
Clients MAY include fields that do not reveal information about the
content of the request, such as Alt-Used ALT-SVC, or information that
it trusts the oblivious proxy resource to remove, such as fields that
are listed in the Connection header field.
Evolution of the format of encapsulated requests and responses is
supported through the definition of new formats that are identified
by new media types.
Clients have the fewest direct responsibilities, though clients do
need to ensure that they do not undermine the process.
Clients MUST ensure that the key configuration they select for
generating encapsulated requests is integrity protected and
authenticated so that it can be attributed to the oblivious request
resource; see key-configuration.
Clients MUST NOT include identifying information in the request that
is encapsulated.
Clients also need to ensure that they correctly generate a new HPKE
context for every request, using a good source of entropy (RANDOM).
Key reuse not only risks linkability, but it could expose request and
response contents to the proxy.
Clients constructing the request that is to be encapsulated need to
avoid including identifying information.  Similarly, the request that
is sent to the oblivious request resource, though this request can
contain only minimal information as it only needs to include a method
and the oblivious request resource URL.
The proxy that serves the oblivious proxy resource has a very simple
function to perform.  It forwards messages received at this resource
to the oblivious request resource, and forwards responses from the
oblivious request resource back to clients.  The proxy MUST forward
response status codes without modification.
The proxy MUST NOT add information about the client identity when
forwarding requests.  This includes the Via field, the Forwarded
field FORWARDED, and any similar information.
Clients MUST generate a new HPKE context for every request, using a
good source of entropy (RANDOM) for generating keys.  Key reuse not
only risks requests being linked, reuse could expose request and
response contents to the proxy.
The request the client sends to the oblivious proxy resource only
requires minimal information; see http-usage.  The request that
carries the encapsulated request and is sent to the oblivious proxy
resource MUST NOT include identifying information unless the client
ensures that this information is removed by the proxy.  A client MAY
include information only for the oblivious proxy resource in header
fields identified by the Connection header field if it trusts the
proxy to remove these as required by Section 7.6.1 of HTTP.  The
client needs to trust that the proxy does not replicate the source
addressing information in the request it forwards.
Clients rely on the oblivious proxy resource to forward encapsulated
requests and responses.  However, the proxy can only refuse to
forward messages, it cannot inspect or modify the contents of
encapsulated requests or responses.
The proxy that serves the oblivious proxy resource has a very simple
function to perform.  For each request it receives, it makes a
request of the oblivious request resource that includes the same
content.  When it receives a response, it sends a response to the
client that includes the content of the response from the oblivious
request resource.  When generating a request, the proxy MUST follow
the forwarding rules in Section 7.6 of HTTP.
A proxy can also generate responses, though it assumed to not be able
to examine the content of a request (other than to observe the choice
of key identifier, KDF, and AEAD), so it is also assumed that it
cannot generate an encapsulated response.
A proxy MUST NOT add information about the client identity when
forwarding requests.  This includes the Via field, the Forwarded
field FORWARDED, and any similar information.
Words...
Please update the "Media Types" registry at
https://www.iana.org/assignments/media-types [1] with the
registration information in media-types for the media types "message/
ohttp-req" and "message/ohttp-res".
Please update the "Media Types" registry at
https://www.iana.org/assignments/media-types [1] with the
registration information in media-types for the media types "message/
ohttp-req", "message/ohttp-res", and "application/ohttp-keys".