From Pete's Gen-ART review:

Nits/editorial comments: Looks fine from a non-security-expert's perspective. It is my duty to ask about keyid in section 2.1:

      A "keyid" parameter SHOULD be a UTF-8
      [RFC3629] encoded string, particularly where the identifier might
      need to appear in a textual form.

I presume that simply means "might need to be rendered" and does not include "might need to be typed in by someone", correct? The former is easy; the latter probably requires a bit more text.

Thanks for producing this specification.

section 3.1: "plaintext = SSBhbSB0aGUgd2FscnVzAg" ?

Thanks for addressing the SecDir review comments:
https://mailarchive.ietf.org/arch/msg/secdir/6TCbjRD3sEBNmZxEhxN7Q4LA0aI

S 2.1.
You should say what idlen is. The QUIC notation here isn't defined :)

S 2.2/2.3.
Can you make clearer that the strings don't have their own null
termination. I.e, that what is fed into the CEK generation function
is  .... 32  38  67  63  6d 00 01
not .... 32  38  67  63  6d 00 00 01


S 4.6.
  
   This mechanism only offers encryption of content; it does not perform
   authentication or authorization, which still needs to be performed
   (e.g., by HTTP authentication [RFC7235]).

This text is kind of confusing, because the mechanism does provide
data origin authentication. I think you mean that if the server is
just going to process this as an opaque and stuff it somewhere, then
it needs extra authentication? This seems like a layering issue.


S 4.7.
Some citations to some of the various padding traffic analysis papers
might be useful.

   Distributing non-padding data is recommended to avoid
   leaking size information.

I think you mean "distributing this across the records".