Draft: draft-thomson-http-oblivious

Commentary: Switches to an 8 - bit key identifier here as well . This format now does n't need varints . Yay . Implemented this in my ohttp library and it 's fine . 
 Splitting this from . It seems likely that a single KEM key will support multiple KDF or AEAD options ( NSS will soon support 3 of the former , and 2 of the latter , maybe 3 of each ) . Having a configuration that includes a single set of ( KEM , key , and key identifier ) with a list of KDF+AEAD pairs , akin to ECH , would make it easier to support that sort of deployment . Without that , key identifiers need to carry information about the KDF and AEAD . To support this , the format needs to be adjusted to carry the KDF and AEAD identifier . In doing so , we probably want to encode the choice of KDF and AEAD in the key schedule or AAD accordingly . 
 Should the key ID length be explicitly authenticated , e.g. , by including it in the AAD , or should the AEAD implicitly authenticate things ? Unclear ! 
 Should we even bother with an AAD at all ? The best reason is that the keyID determines which key the server uses , which is information that factors into decisions . ( A related question might be why does n't HPKE take variables as input so that things like key identifiers can be integrated into the key schedule . ) 
 My take : yes . I need to think through the implications of no additional authentication at all , and in the mean time , I 'd be more comfortable with simply authenticating everything possible . I think it was discussed , but it makes the interface a mess . And since applications can accomplish the same thing by shoving what they want authenticated into the AAD , it was voted down . 
 Yeah , you and I both know that putting stuff in the AAD is n't a real substitute for having it in the key schedule . I completely understand how this would mess with the purity of the design , but TLS managed by wrapping its labels better ( which also addresses a known problem with HKDF not being injective ) . 
 Fixed by virtue of making the key ID fixed length in .
This draft uses the variable-length integer encoding from Section 16
of QUIC.  Encoding and decoding variable-length integers to a
sequence of bytes are described using the functions "vencode()" and
"vdecode()".  The function "len()" takes the length of a sequence of
bytes.
Encoding an integer to a sequence of bytes in network byte order is
described using the function "encode(n, v)", where "n" is the number
of bytes and "v" is the integer value.  The function "len()" returns
the length of a sequence of bytes.
Encrypt (seal) "request" with "keyID" as associated data using
"context", yielding ciphertext "ct".
Concatenate the length of "keyID" as a variable-length integer,
"keyID", "enc", and "ct", yielding an Encapsulated Request
"enc_request".  Note that "enc" is of fixed-length, so there is no
ambiguity in parsing "enc" and "ct".
Parses "enc_request" into "keyID", "enc", and "ct" (indicated
using the function "parse()" in pseudocode).  The server is then
able to find the HPKE private key, "skR", corresponding to
"keyID".  If no such key exists, the server returns an error; see
errors.
Construct additional associated data, "aad", as the Key Identifier
"keyID" from "enc_request".
the key identifier from the configuration, "keyID",
a selected combination of KDF, identified by "kdfID", and AEAD,
identified by "aeadID".
Construct associated data, "aad", by concatenating the values of
"keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers
respectively, each in network byte order.
Encrypt (seal) "request" with "aad" as associated data using
"context", yielding ciphertext "ct".
Concatenate the three values of "aad", "enc", and "ct", yielding
an Encapsulated Request "enc_request".
Note that "enc" is of fixed-length, so there is no ambiguity in
parsing this structure.
Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and
"ct" (indicated using the function "parse()" in pseudocode).  The
server is then able to find the HPKE private key, "skR",
corresponding to "keyID".
a.  If "keyID" does not identify a key, the server returns an
error.
b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD
that the server is unwilling to use with "skR", the server returns
an error.
Construct additional associated data, "aad", from "keyID",
"kdfID", and "aeadID" or as the first five bytes of "enc_request".