Re: Secdir last call review of draft-ietf-httpbis-compression-dictionary-09

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@google.com> 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,
>
> -Pat
>
> On Wed, Aug 7, 2024 at 7:03 PM Nancy Cam-Winget via Datatracker <
> noreply@ietf.org> 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?)
>>
>>
>>
>>