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