Change:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don'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 can'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 don'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.

Discussion:
The client then constructs an encapsulated request, "enc_request", as follows: <del> Compute an HPKE context using "pkR" and a label of "ohttp </del> <ins> Compute an HPKE context using "pkR" and a label of "message/bhttp </ins> request", yielding "context" and encapsulation key "enc". Construct associated data, "aad", by concatenating the values of

that the server is unwilling to use with "skR", the server returns an error. <del> Compute an HPKE context using "skR", a label of "ohttp request", and the encapsulated key "enc", yielding "context". </del> <ins> Compute an HPKE context using "skR", a label of "message/bhttp request", and the encapsulated key "enc", yielding "context". </ins> Construct additional associated data, "aad", from "keyID", "kemID", "kdfID", and "aeadID" or as the first seven bytes of

response "response", servers generate an Encapsulated Response "enc_response" as follows: <del> 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". </del> <ins> 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". </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

cannot be successfully decrypted using the key. A server MUST ensure that the HPKE keys it uses are not valid for any <del> other protocol that uses HPKE with the "ohttp request" label. </del> <ins> other protocol that uses HPKE with the "message/bhttp request" label. </ins> Designers of other protocols, especially new versions of this protocol, can ensure key diversity by choosing a different label in <del> their use of HPKE.  The "ohttp response" label was chosen for </del> <ins> their use of HPKE.  The "message/bhttp response" label was chosen for </ins> symmetry only as it provides key diversity only within the HPKE <del> context created using the "ohttp request" label. </del> <ins> context created using the "message/bhttp request" label. </ins> 8.4.

11. <ins> 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. 12. </ins> 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". <del> 12.  References </del> <ins> 13.  References </ins> <del> 12.1.  URIs </del> <ins> 13.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types