Quick follow-up...
As an example of where it makes deployment a little easier, for the case of static resources (like a _javascript_ bundle) where the deltas are generated at build time and stored as something like "example.js.<hash>.brd", The serving path for the resource doesn't need to calculate the hash of example.js when it is served and doesn't need to make sure the ID matches the specific payload. It can be configured to serve a static "Use-As-Dictionary: " response header with just a match path and the same header can work as new versions of the resource roll out.
At serving time, if there is an "Available-Dictionary" request header, the server can first check to see if "example.js.<hash>.brd" exists with a matching hash and serve it if there is one (and fall back to the full example.js if there isn't). By varying on the encoding and available-dictionary, any CDN's can cache the dictionary-specific response which minimizes the amount of dynamic logic that needs to run to serve dictionary-compressed deltas.
On Wed, Aug 7, 2024 at 7:40 PM Patrick Meenan <pmeenan@xxxxxxxxxx> wrote:
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,-PatOn 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
