Re: Mahesh Jethanandani's Discuss on draft-ietf-httpbis-unencoded-digest-04: (with DISCUSS and COMMENT)

Hi Mahesh.

Thanks for the review 

On Mon, Mar 30, 2026, at 15:41, Mahesh Jethanandani via Datatracker wrote:
> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-httpbis-unencoded-digest-04: 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-unencoded-digest/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This particular DISCUSS should be easy to address.
> 
> Section 2, paragraph 1
> >    This document uses the Augmented BNF defined in [RFC5234] and updated
> >    by [RFC7405].  This includes the rules: LF (line feed)
> 
> RFC 5234 and RFC 7405 are listed as normative references, yet no ABNF grammar
> is defined anywhere in this document. It appears that these RFCs are being
> cited for defining the meaning of "LF". The authors should either remove RFC
> 5234 and RFC 7405 as normative references and rephrase the LF reference inline
> (e.g., "followed by a line feed (0xA)"), or confirm what normative ABNF use
> this document makes justify retaining the two RFCs as normative references.
Its a deviation from RFC 9530 but I can live with a change here.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1, paragraph 5
> >    For a variety of reasons, decoding and re-encoding content in order
> >    to benefit from HTTP integrity fields is not preferable.  This
> >    specification defines the Unencoded-Digest and Want-Unencoded-Digest
> >    fields to support a simpler validation workflow in some scenarios
> >    where content coding is applied.  These fields complement the other
> >    integrity fields defined in [DIGEST-FIELDS].
> 
> There is an implicit assumption that this draft does not state explicitly, i.e.,
> the server must know the digest of the complete unencoded resource before it
> sends the first chunk. That means:
> 
> - The server cannot compute Unencoded-Digest on-the-fly as it streams/encodes
> data. - It must either have pre-computed the digest and stored it, or buffer
> the entire unencoded content first, hash it, then start sending.
> 
> This is actually a non-trivial constraint that the draft glosses over.
> RFC 9530 discusses the streaming vs. pre-computation trade-off for Repr-Digest
> in Section 6.1 ("Digest and Content-Encoding"), but this document just says
> Unencoded-Digest "behaves similarly to Repr-Digest" and leaves it at that.
> 
> This draft should explicitly note that Unencoded-Digest cannot be computed
> lazily during transmission, and requires the server to have prior knowledge
> of the digest of the complete unencoded representation — either from storage
> or pre-computation. This is a meaningful deployment consideration for servers
> handling large objects or dynamically generated content, and it belongs to
> either in Section 3 or Section 5.

I disagree with this assessment. A server sending a representation with no content coding can calculate the Unencoded-Digest on the fly and send it in a trailers if it so wishes. Section 3 makes it clear the field is allowed in trailers, as required to be stated by Section 16.3.2 of RFC 9110.

I'm not sure what part of RFC 9530 you're referring to. Section 6.1 of RFC 9530 is titled "HTTP Messages Are Not Protected in Full". The whole of RFC 9530 has a pretty light touch wrt trailers, and the unencoded-digest draft has a similar amount.
> 
> Section 4, paragraph 5
> >    *  value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that
> >       conveys an ascending, relative, weighted preference.  It must be
> >       in the range 0 to 10 inclusive. 1 is the least preferred, 10 is
> >       the most preferred, and a value of 0 means "not acceptable".
> 
> This section uses lowercase "must," leaving the normative force ambiguous. RFC
> 9530 Section 4 uses the same lowercase "must" for Want-Repr-Digest, so this is
> consistent with the parent document. Nevertheless, if senders generating
> out-of-range values would cause interoperability failures, this should be
> "MUST". A brief clarifying note (e.g., whether the Structured Fields Integer
> type already enforces this, which would make the normative level moot) would
> help.
Structured Fields has no opinion on the rules applied on top of its own. I think maintaining consistency with RFC 9530 is the important thing to do here.
> 
> Section 7, paragraph 2
> >    A content coding may provide encryption capabilities, for example
> >    "aes128gcm" ([RFC8188]).  Using Unencoded-Digest with such content
> >    codings can leak information about the original data because header
> >    fields are visible to anyone who can read the HTTP message.  This
> >    could be used as a side channel.  For instance, an attacker that can
> >    access Unencoded-Digest values could infer details about the
> >    unencrypted content without decrypting it if, for example, the
> >    unencrypted content has a predictable pattern.  When the "aes128gcm"
> >    content coding is used, the security considerations in Section 4 of
> >    [RFC8188] apply.
> 
> I support Deb's comment on the use of a SHOULD NOT for combining
> Unencoded-Digest with encryption-capable content codings.
> 
> In addition, agree with Mallory on changing 'may' to 'might'. This is an
> informative "may" (describing a possibility, not a permission), but it sits in
> a section full of normative language and could be misread. Changing to "might"
> aligns with RFC 8174 guidance might, and reduces ambiguity.
Please see my response to Deb's review wrt SHOULD NOT.

Wrt use of may or might, I think this has come up a couple of times so we can change it to the proposed text.

Cheers,
Lucas
> 
> 
> 
>