Skip to main content

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?)