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

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.


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

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.

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.

Received on Monday, 30 March 2026 14:41:47 UTC