Draft: draft-ietf-ohai-ohttp

Commentary: Test vectors generated from the . 
 With , we 're enforcing a 1:1 mapping between message / ohttp - req and message / bhttp , but we do n't have any cryptographic enforcement of this pairing . If someone were to reuse the encapsulation mechanism in this document with another message type , say , to encapsulate application / dns - message values with a application / oblivious - dns - message wrapper , then we 'd probably want to ensure that targets ca n't get confused between these two types . We could use the HPKE info string to separate these two protocols . ( This is related to . ) 
 The encapsulated payload could be something other than HTTP . We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that . 
 The clear example here would be allowing just a DNS message body . As long as the client and target agreed , they could use that without the proxy knowing . We could just loosen the restrictions on what the body is , or we could use different content types ( if you want the proxy to know what it is ? ) . 
 I think that the way you would do that is to define a new media type for DNS and then just go for it . ( Of course , you need to debate whether to include a length field and a transaction ID field . ) Maybe we do n't need to do that in this draft , but we could explain how that might look . 
 I 'd do the following here ( in line with ): Replace as the HPKE info string with the content - type of the inner message , be it or . That way , both client and target must agree on the type of encapsulated payload to actually use it . Thoughts ? 
 That might work . We have " ohttp response " as the label for HKDF expansion on the response . What would you include there ? Maybe you should just extend with " message / bhttp request " and " message / bhttp response " and then the swapping in the media type becomes trivial . 
 Yeah , that 's what I had in mind . 
 Sorry about that . Misremembered how this worked ; I should have double - checked .
Compute an HPKE context using "pkR" and a label of "ohttp
request", yielding "context" and encapsulation key "enc".
Compute an HPKE context using "pkR" and a label of "message/bhttp
request", yielding "context" and encapsulation key "enc".
Compute an HPKE context using "skR", a label of "ohttp request",
and the encapsulated key "enc", yielding "context".
Compute an HPKE context using "skR", a label of "message/bhttp
request", and the encapsulated key "enc", yielding "context".
Export a secret "secret" from "context", using the string "ohttp
response" as context.  The length of this secret is "max(Nn, Nk)",
where "Nn" and "Nk" are the length of AEAD key and nonce
associated with "context".
Export a secret "secret" from "context", using the string
"message/bhttp response" as context.  The length of this secret is
"max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and
nonce associated with "context".
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "ohttp request" label.
Designers of other protocols, especially new versions of this
protocol, can ensure key diversity by choosing a different label in
their use of HPKE.  The "ohttp response" label was chosen for
symmetry only as it provides key diversity only within the HPKE
context created using the "ohttp request" label.
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "message/bhttp request" label.
Designers of other protocols, especially new versions of this
protocol, can ensure key diversity by choosing a different label in
their use of HPKE.  The "message/bhttp response" label was chosen for
symmetry only as it provides key diversity only within the HPKE
context created using the "message/bhttp request" label.
The encapsulated payload of an OHTTP request and response is a binary
HTTP message BINARY.  Client and target agree on this encapsulated
payload type by specifying the media type "message/bhttp" in the HPKE
encapsulation info string and HPKE export context string for request
and response encapsulation, respectively.
Future specifications may repurpose the encapsulation mechanism
described in hpke-encapsulation, provided that the content type of
the encapsulated payload is appropriately reflected in the HPKE info
and context strings.  For example, if a future specification were to
use the encapsulation mechanism in this specification for DNS
messages, identified by the "application/dns-message" media type,
then the HPKE info string SHOULD be "application/dns-message request"
for request encapsulation, and the HPKE export context string should
be "application/dns-message response" for response encapsulation.