Comments on draft-ietf-httpbis-encryption-encoding-04

Please find some comments on the most recent revision.

-Ekr

SUBSTANTIVE
S 2.1.
  The "rs" or record size parameter contains an unsigned 32-bit
  integer in network byte order that describes the record size in
  octets.  Note that it is therefore impossible to exceed the
  2^36-31 limit on plaintext input to AEAD_AES_128_GCM.  Values
  smaller than 3 are invalid.

I don't believe that this is correct, because the limit is on the
total number of bytes with the same key, not on the total number
of bytes with one nonce.

S 2.2.
   Why are you using the terminal 0x00 here? I don't see anywhere
   else you HMAC on cek_info without it.


S 3.
This whole Crypto-Key thing seems like a menace. As has been noted,
it's a terrible idea to provide Crypto-Key and encrypted data
for the same key in the same HTTP message, but that's the only
thing you see to support:

   The value or values provided in the Crypto-Key header field is valid
   only for the current HTTP message unless additional information
   indicates a greater scope.

Do we have a concrete use case for Crypto-Key? If not, I would remove
it. If so, I would consider writing a different spec.




EDITORIAL
S 2.
You should put the graf starting with "The record size" above the diagram
because the diagram rs.

  To prevent an attacker from truncating a stream, an encoder
  MUST append a record that contains only padding and is smaller than
  the full record size if the final record ends on a record boundary.

I would invert the logic here. I.e.,

  If the final record ends on a record boundary, the encoder MUST
  append a record that contains...


  Each record contains between 2 and 65537 octets of padding, inserted
  into a record before the enciphered content.

I think it's kind of a mistake to treat the padding length as part of the
padding.


  A consequence of this record structure is that range requests
  [RFC7233] and random access to encrypted payload bodies are possible
  at the granularity of the record size.  Partial records at the ends
  of a range cannot be decrypted.  Thus, it is best if range requests
  start and end on record boundaries.

This is sort of true, but it's not like you can randomly access the
underlying data because there might be padding and you don't know.



S 2.2.
   In order to allow the reuse of keying material for multiple different
   HTTP messages, a content encryption key is derived for each message.
   The content encryption key is derived from the decoded value of the
   "salt" parameter using the HMAC-based key derivation function (HKDF)
   described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4].

"decoded value" is weird here.