Re: Roman Danyliw's Discuss on draft-ietf-httpbis-compression-dictionary-13: (with DISCUSS and COMMENT)

Thank you for the feedback. It looks like Mark already addressed the whatwg
references but I'm happy to make any changes there if needed (like linking
to specific anchors) (I was mostly copying what the existing RFCs had done).

> ** Section 4.  This section provides normative guidance that relies on
> [SHARED-BROTLI].
>
> -- As such, [SHARED-BROTLI] needs to be a normative reference.

I have a draft ready with this change (as well as moving the ZStandard
[RFC8878] reference to being normative since it is used in the same way as
the [SHARED-BROTLI] reference). Just holding off on publishing until we
come to agreement on if the expired ID is sufficient or if something needs
to be done on that front first.

> > -- Is the WG confident that this reference has sufficient
stability/review for
> use?  I ask because [SHARED-BROTLI] appears to be an expired, individual
I-D.

The implementation in the reference Brotli implementation has been stable
since before the ID was created and documents what has been shipping for a
few years. I've asked the team to see if we can move the expired ID forward
to an informative RFC but I can pick up that mantle if it ends up being a
blocker (I'm not particularly familiar with the compression spade itself
but happy to help make it happen).

> ** Section 4 and 5.  Both of these sections specify a fixed size header
> (36-bytes and 40 bytes) that includes a SHA-256 hash. Is this document the
> authoritative source for defining these headers?

Yes.

> If so, is it expected that
> this SHA-256 hash would provide imbue any security properties?  I ask
because
> the use of SHA-256 is hard coded and there is no means for algorithm
agility.

No. It is the same hash that is used in the Available-Dictionary
negotiation and used more as an identifier to minimize the risk of the
dictionary not matching what the client was expecting (or having been
corrupted somewhere in the path). The actual security protections come from
the same-origin restrictions and secure transmission. Section 9 covers the
security mechanisms that are actually relied upon.

The expectation is that if a new hash ends up being needed at some point in
the future that a new content-encoding will be defined (with a different
magic header) so the flexibility is available if sha-256 is ever determined
not to be sufficient to be used as an ID for the dictionaries.

Thanks,

-Pat

On Tue, Aug 20, 2024 at 8:29 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-httpbis-compression-dictionary-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ** How to best cite living specifications?
>
>    [FETCH]    WHATWG, "Fetch - Living Standard", June 2024,
>               <https://fetch.spec.whatwg.org>.
>    [URLPattern]
>               WHATWG, "URL Pattern - Living Standard", March 2024,
>               <https://urlpattern.spec.whatwg.org/>.
>
> Realizing that these are living specifications, I don’t understand how the
> above citations are providing stable references.  How does one get the
> “March
> 2024 version” of “URL Pattern”?  Is there a specific GitHub commit
> reference
> that can be used instead?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Reese Enghardt for the GENART review.
>
> ** Section 4.  This section provides normative guidance that relies on
> [SHARED-BROTLI].
>
> -- As such, [SHARED-BROTLI] needs to be a normative reference.
>
> -- Is the WG confident that this reference has sufficient stability/review
> for
> use?  I ask because [SHARED-BROTLI] appears to be an expired, individual
> I-D.
>
> ** Section 4 and 5.  Both of these sections specify a fixed size header
> (36-bytes and 40 bytes) that includes a SHA-256 hash. Is this document the
> authoritative source for defining these headers?  If so, is it expected
> that
> this SHA-256 hash would provide imbue any security properties?  I ask
> because
> the use of SHA-256 is hard coded and there is no means for algorithm
> agility.
>
>
>
>