Last Call Review of draft-ietf-httpbis-compression-dictionary-09
review-ietf-httpbis-compression-dictionary-09-secdir-lc-cam-winget-2024-08-07-00
Request | Review of | draft-ietf-httpbis-compression-dictionary |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-08-06 | |
Requested | 2024-07-23 | |
Authors | Patrick Meenan , Yoav Weiss | |
I-D last updated | 2024-08-07 | |
Completed reviews |
Artart Last Call review of -16
by Darrel Miller
(diff)
Genart Last Call review of -08 by Reese Enghardt (diff) Secdir Last Call review of -09 by Nancy Cam-Winget (diff) |
|
Assignment | Reviewer | Nancy Cam-Winget |
State | Completed | |
Request | Last Call review on draft-ietf-httpbis-compression-dictionary by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/c7C85J8aOmItlttjwLrgUwRY4F0 | |
Reviewed revision | 09 (document currently at 19) | |
Result | Ready | |
Completed | 2024-08-07 |
review-ietf-httpbis-compression-dictionary-09-secdir-lc-cam-winget-2024-08-07-00
SECDIR review of draft-ietf-httpbis-compression-dictionary-09 Reviewer: Nancy Cam-Winget 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. This document defines HTTP headers that can be used for negotiating for enabling compression by using dictionaries. The negotiation defines an external dictionary that provides the mapping or patterns to decode when compression is enabled. The document leverages the use of Brotli (RFC7932) and Standard (RFC8878) as the compression schemes. The document reads well and I have found no issues but have One minor question: Section 2.2 * Is the intent of providing the hash of the "Available-Dictionary" meant to be for protection or for compression? Section 9.1 * To my point in Section 2.2, we presume that all headers are encrypted and protected, so I think it would depend on what protection is being achieved. That is, I think it should be stated that if the header protection is found to be weak, this can be made vulnerable too (I think this is somewhat covered in 9.2 maybe?)