Re: draft-ietf-httpbis-unencoded-digest-03 ietf last call Genart review

Hi Mallory,

Many thanks for the review. I plan to create a PR (or several) that incorporates ypur feedback and will follow up with a link to that. In the meantime please see some in line responses below:

On Tue, Jan 6, 2026, at 15:39, Mallory Knodel via Datatracker wrote:
> Document: draft-ietf-httpbis-unencoded-digest
> Title: HTTP Unencoded Digest
> Reviewer: Mallory Knodel
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> 
> Document: draft-ietf-httpbis-unencoded-digest-??
> Reviewer: Mallory Knodel
> Review Date: 2026-01-06
> IETF LC End Date: 2026-01-14
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document defines a third set of integrity fields,
> unencoded-digest/want-unencoded-digest and updates RFC 9530 with this
> terminology and specifications.
> 
> Major issues: None. It's a well-written document and the history of the
> document was so well organized I was really able to appreciate the evolution
> from gap analysis, through naming changes, and to this final version.
Thanks for the kind words.
> 
> Minor issues: Perhaps a consideration for mitigating the security issue
> introduced by this spec and described in security considerations-- maybe a
> 'SHOULD NOT' for implementations that use content coding with encryption
> capabilities. Or another pointer back to RFC 9530 if appropriate.

I do appreciate the observation. Generally speaking I'm not a fan of putting normative statements in the security considerations section. In this specific case, I don't think the authors have a strong opinion on the security posture, so any recommendations might be hard for us to justify. For instance, if we were to say SHOULD NOT, then under what conditions would it be ok? (For avoidance of doubt, this is meant as a rhetorical question).

The text was added fairly recently [1] and attempted to channel some of the spirit of RFC8188's security considerations. My hope is that anyone using these two specs together would be competant in considering all factors needed to address their threat model.

I'd like to see if reviews from the SEC area flag this too and whether they might have some oponions on whether text improvements make sense.

> 
> Nits/editorial comments:
> 
> * Security considerations-- Change 'may' to 'might' in, "A content coding may
> provide encryption capabilities, for example "aes128gcm" ([RFC8188])."
Agreed!
> 
> * This is probably my unfamiliarity with convention, so please ignore it if
> I'm going against established practise, but the first three normative
> references use a name rather than RFC number, which as a reader led me to
> believe they were internet-drafts until I arrived at the end and saw the RFC
> number in the URL of the reference-- this did have an impact on how I read the
> document, assuming the document's core references were not yet standards.
So, some of this comes directly from the HTTP style guide [2]. The named reference to FOLDING maintains consistency with RFC 9530. In my experience, many documents coming out of the WIT area tend to use a mix of styles due to dependencies on HTTP and TLS.
> 
> * Section 6: Suggest rewriting, "The second example demonstrates a range
> request with content negotiation." to "The second example demonstrates a range
> request that uses content negotiation." for easier comparison between the two
> examples.
Agreed we can make these more consistent.
> 
> * Not entirely clear from an implementation perspective what the relationship
> would be between Accept-Encoding header field with identity, and the use of
> Unencoded-digest. It's only briefly mentioned in describing the problem, but
> perhaps it would be conceptually useful for the reader to elaborate what this
> might look like in practice in Section 5.
> 

So this one is a bit tricksy for a few reasons. 

Section 5 is titled "Messages containing both Unencoded-Digest and Content-Encoding". If Accept-Encoding: identity were sent and respected, there would be no Content-Encoding reaponse header (assuming the server adheres to RFC 9110 [3].)

There is some text in section 3 that touches on the matter [4]

> The `Unencoded-Digest` HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the entire selected representation data with no content codings applied (Section 8.4.1 <https://rfc-editor.org/rfc/rfc9110#section-8.4.1> of [HTTP <https://www.ietf.org/archive/id/draft-ietf-httpbis-unencoded-digest-03.html#HTTP>]).
> Apart from the content coding concerns, `Unencoded-Digest` behaves similarly to `Repr-Digest` (Section 3 <https://rfc-editor.org/rfc/rfc9530#section-3> of [DIGEST-FIELDS <https://www.ietf.org/archive/id/draft-ietf-httpbis-unencoded-digest-03.html#DIGEST-FIELDS>]). In the absence of content codings, `Unencoded-Digest` is identical to `Repr-Digest`.

An earlier version of this draft [5] included an example that demonstrated a response with both fields but the feedback was that it was a bit contrived and unrealistic for a server to send three fields all with the same value.

The examples in section 6 take care to avoid that trap and contain different values for each field to highlight the conceptual differences. 

I'm also a bit nervous about stepping onto a slippery slope of trying to explain everythingb about HTTP semantics, especially if its "by example" which can rarely be complete. 

Is there perhaps some succinct statement that could have aided you as a reader ? I'd be happy to add some minor clarification or explocit assertion somewhere.

Cheers
Lucas


[1] https://github.com/httpwg/http-extensions/pull/3347
[2] https://httpwg.org/admin/editors/style-guide#reference-style
[3] https://www.rfc-editor.org/rfc/rfc9110.html#section-8.4
[4] https://www.ietf.org/archive/id/draft-ietf-httpbis-unencoded-digest-03.html#section-3-2
[5] https://www.ietf.org/archive/id/draft-pardue-http-identity-digest-01.html