Thank you for the review.
The intent of providing the hash of the "Available-Dictionary" is to be sure that the contents of the dictionary on the client are the same as what the server is using for the compression (more for integrity than anything else). It also acts as a default identifier in the negotiation if an explicit ID isn't provided. Both ZStandard and Brotli also use hashes to verify the dictionary before decompression to prevent corruption but providing it in the request header allows for the server to not send an invalid response in the first place in case the payloads got modified somewhere in the path previously or something else got out of sync.
It is allowed (and expected) that there may be multiple dictionaries for the same resource (i.e. version 1.1 of example.js and version 1.2 of example.js both used as dictionaries for version 1.3 for different delta updates) and the hash makes differentiating them automatic (and standard).
It's not meant as a protection against explicit attack - that is expected to be handled by the transport itself (encryption, cert verification, etc). An attack on the dictionary or payload would have the same risks and vulnerabilities as an attack on the uncompressed response itself (that part is where the same-origin dictionary/payload requirement comes from).
Thanks,
-Pat
On Wed, Aug 7, 2024 at 7:03 PM Nancy Cam-Winget via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Nancy Cam-Winget
Review result: Ready
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?)
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
