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

I just published draft 14 which changed the shared brotli and ZStandard
references to be normative and changed the references to the fetch spec to
use anchors to the relevant parts of the spec.

That should be stable long-term and make it easier for readers of the
compression dictionaries spec to find the specific parts of fetch that are
needed.  URL Pattern is the only other whatwg spec referenced but deep
links there didn't seem necessary since the whole spec is applicable (I can
change it to deep-link to the URLPattern class if you think it would help).

The main question remaining that has come up a few times is if a normative
reference to an expired draft in the case of the shared brotli stream
format is appropriate (and if not, what the best solution would be).

https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/14/

Thanks,

-Pat

On Tue, Aug 20, 2024 at 9:11 PM Patrick Meenan <pmeenan@google.com> wrote:

> 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.
>>
>>
>>
>>