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

[Patrick Meenan <[e-mail]>]

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 <
[e-mail]> 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?)
>
>
>
>