Last Call Review of draft-ietf-httpbis-encryption-encoding-08
review-ietf-httpbis-encryption-encoding-08-secdir-lc-sparks-2017-04-05-00
Request | Review of | draft-ietf-httpbis-encryption-encoding |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2017-04-06 | |
Requested | 2017-03-23 | |
Authors | Martin Thomson | |
I-D last updated | 2017-04-05 | |
Completed reviews |
Opsdir Last Call review of -08
by Al Morton
(diff)
Genart Last Call review of -08 by Pete Resnick (diff) Secdir Last Call review of -08 by Robert Sparks (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Last Call review on draft-ietf-httpbis-encryption-encoding by Security Area Directorate Assigned | |
Reviewed revision | 08 (document currently at 09) | |
Result | Ready | |
Completed | 2017-04-05 |
review-ietf-httpbis-encryption-encoding-08-secdir-lc-sparks-2017-04-05-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document : draft-ietf-httpbis-encryption-encoding-08 Summary: This document is ready for publication as Proposed Standard (except perhaps for one recommendation) This document defines a content encoding for encrypting the contents of an HTTP message that facilitates storing the encrypted contents and decrypting the content for rendering incrementally (before the full content is received). The draft is clear, and implementation should be straightforward. It's security considerations section is detailed. I did not verify the math that went into the provided examples. My only concern is that the document suggests it would be ok to use a counter to provide a unique salt value for each message. I suspect that provides the kind of information leak the draft discusses avoiding. I also pointed out a couple of nits to the editor, and those are addressed already in his working copy (on github).