Skip to main content

Encrypted Content-Encoding for HTTP
draft-ietf-httpbis-encryption-encoding-09

Yes

(Alexey Melnikov)
(Ben Campbell)

No Objection

Warren Kumari
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Suresh Krishnan)

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

Warren Kumari
No Objection
Alexey Melnikov Former IESG member
Yes
Yes (for -08) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2017-04-11 for -08) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2017-04-11 for -08) Unknown
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".
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-04-13 for -08) Unknown
Thanks for addressing the SecDir review comments:
https://mailarchive.ietf.org/arch/msg/secdir/6TCbjRD3sEBNmZxEhxN7Q4LA0aI
Mirja K├╝hlewind Former IESG member
No Objection
No Objection (2017-04-11 for -08) Unknown
section 3.1: "plaintext = SSBhbSB0aGUgd2FscnVzAg" ?
Spencer Dawkins Former IESG member
No Objection
No Objection (2017-04-12 for -08) Unknown
Thanks for producing this specification.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08) Unknown