Draft: draft-ietf-ohai-ohttp

Commentary: This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct . This builds on top of ( which we are going to merge soon ) because that hits all the same text and we have already effectively agreed to those changes . You can review to see what the substance of these changes are . Alternatively , just look at the top of the " HPKE Encapsulation " section ( the other changes are unrelated ) . 
 I spent some time being confused because ( content type ) and ( the hpke info tag ) are so similar . Is it possible to align these two ? Section 9 , Repurposing the Encapsulation Format , mentions changing the hpke info for other protocols , so I suppose is re - using the content - type from the binary http draft at this layer , while the outer Content - Type is specific to this draft 's application ? I can see the logic there , but some clarifying text about the two being different would have been helpful . 
 We kept them separate because they refer to different things . The " message / ohttp - req " content type refers to the type of HTTP request sent from client to gateway , whereas the " message / bhttp request " content type refers to the type of content that 's encapsulated to the gateway . We can probably improve this distinction in the text . Thanks for flagging this . 
 I did a little rewriting of some of the key framing text for another issue , does the following help at all ? 
 The new references to the repurposing section in that commit are helpful . The extra wording you linked does n't help much I think . It 's confusing that the both encapsulates a and is called an ' encapsulated request / response ' . So when you say , the word ' contains ' is ambiguous : is it that the directly contains the binary HTTP message , or is that the HPKE AEAD contains the binary HTTP message ? I understand it 's the second one , but on first reading this kind of layer confusion was hard to keep track of . Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help ? 
 I took a swing at this in . Am I getting closer ?
HTTP message encapsulation uses HPKE for request and response
encryption.
An encapsulated HTTP request contains a binary-encoded HTTP message
BINARY and no other fields; see fig-req-pt.
An is comprised of a key identifier and a HPKE-protected request
message.  HPKE protection includes an encapsulated KEM shared secret
(or "enc"), plus the AEAD-protected request message.  An is shown in
fig-enc-request. request describes the process for constructing and
processing an .
An encrypted HTTP response includes a binary-encoded HTTP message
BINARY and no other content; see fig-res-pt.
Responses are bound to requests and so consist only of AEAD-protected
content.  response describes the process for constructing and
processing an .
An format defined in req-format is identified by the iana-req.
An format defined in res-format is identified by the iana-res.
Alternative encapsulations or message formats are indicated using the
media type; see req-res-media and repurposing.
A message in ""message/ohttp-req"" format protects a binary HTTP
request message; see fig-req-pt.
This plaintext Request is encapsulated into a message in ""message/
ohttp-req"" form by generating an .  An is comprised of a key
identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the
encapsulated KEM shared secret (or "enc"); and the HPKE-protected
binary HTTP request message.
An is shown in fig-enc-request. request describes the process for
constructing and processing an .
A message in ""message/ohttp-res"" format protects a binary HTTP
response message; see fig-res-pt.
This plaintext Response is encapsulated into a message in ""message/
ohttp-res"" form by generating an .  An is comprised of a nonce and
the AEAD-protected binary HTTP response message.
An is shown in fig-enc-response. response describes the process for
constructing and processing an .
Build "info" by concatenating the ASCII-encoded string "message/
bhttp request", a zero byte, and the header.
Build "info" by concatenating the ASCII-encoded string "message/
bhttp request", a zero byte, and the header.  Note: repurposing
discusses how alternative message formats might use a different
"info" value.
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".
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".  Note: repurposing discusses how
alternative message formats might use a different "context" value.
Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified
by new media types.
Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified
by new media types.  New media types might be defined to use similar
encapsulation with a different HTTP message format than in BINARY;
see repurposing for guidance on reusing this encapsulation.
Alternatively, a new encapsulation method might be defined.
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  The and agree on this encrypted payload type by
specifying the media type "message/bhttp" in the HPKE info string and
HPKE export context string for request and response encryption,
respectively.
Future specifications may repurpose the encapsulation mechanism
described in this document.  This requires that the specification
define a new media type.  The encapsulation process for that content
type can follow the same process, using new constant strings for the
HPKE info and exporter context inputs.
For example, a future specification might encapsulate DNS messages,
which use the "application/dns-message" media type RFC8484.  In
creating a new, encrypted media types, specifications might define
the use of string "application/dns-message request" (plus a zero byte
and the header for the full value) for request encryption and the
string "application/dns-message response" for response encryption.
can use padding to reduce the effectiveness of traffic analysis.
Padding is a capability provided by binary HTTP messages; see BINARY.
can use padding to reduce the effectiveness of traffic analysis.
Padding is a capability provided by binary HTTP messages; see BINARY.
If the encapsulation method described in this document is used to
protect a different message type (see repurposing), that message
format might need to include padding support.
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 protocols that reuse this encryption format, 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; see repurposing-the-encapsulation-format.
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 protocols that reuse this encryption format, 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; see repurposing.
The encrypted payload of an OHTTP request and response is a binary
HTTP message BINARY.  and target agree on this encrypted payload type
by specifying the media type "message/bhttp" in the HPKE info string
and HPKE export context string for request and response encryption,
respectively.
Future specifications may repurpose the encapsulation mechanism
described in hpke-encapsulation, provided that the content type of
the encrypted payload is appropriately reflected in the HPKE info and
context strings.  For example, if a future specification were to use
the encryption 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
encryption, and the HPKE export context string should be
"application/dns-message response" for response encryption.