Encrypted Content-Encoding for HTTP
RFC 8188

Note: This ballot was opened for revision 08 and is now closed.

Ben Campbell Yes

Alexey Melnikov Yes

Alia Atlas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2017-04-11 for -08)
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.

Spencer Dawkins No Objection

Comment (2017-04-12 for -08)
Thanks for producing this specification.

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja K├╝hlewind No Objection

Comment (2017-04-11 for -08)
section 3.1: "plaintext = SSBhbSB0aGUgd2FscnVzAg" ?

Kathleen Moriarty No Objection

Comment (2017-04-13 for -08)
Thanks for addressing the SecDir review comments:

Eric Rescorla (was Discuss) No Objection

Comment (2017-04-11 for -08)
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".

Alvaro Retana No Objection