Re: Deb Cooley's No Objection on draft-ietf-httpbis-unencoded-digest-04: (with COMMENT)

side channel sentence:  Section 4 para 2 of RFC 8188 uses side channel in
the way that I normally see it used, while Section 4.6 uses side-channel
(w/ a hyphen) differently. Given this conflicting use (does the hyphen make
that big of a difference?), I think dropping the sentence is the best
option.

SHOULD NOT?:  The rework of this sentence into two sentences looks much
better.

Thank you for your consideration.
Deb

On Mon, Mar 30, 2026 at 11:17 AM Lucas Pardue <lucas@lucaspardue.com> wrote:

> Hi Deb,
>
> Thanks for the review. Please see responses in line
>
> On Sun, Mar 29, 2026, at 13:16, Deb Cooley via Datatracker wrote:
>
> Deb Cooley has entered the following ballot position for
> draft-ietf-httpbis-unencoded-digest-04: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to Rifaat Shekh-Yusef for their secdir reviews.
>
> Please note that while I am balloting 'no obj', I do feel like some minor
> tweaks make sense.  I am happy to have a conversation (in avoidance of the
> 'd'
> word).
>
> Section 7, para 2:  I expected a 'SHOULD NOT' use an Unencoded-Digest in
> this
> circumstance.
>
> Section 7, para 2:  I'm not sure I would call the inference of 'details
> about
> the unencrypted content with out decrypting it' a 'side channel' per se.
> Most
> commonly, we talk about side channels leaking key, not leaking plain text.
> With no loss of clarity, I would suggest merely deleting this sentence:
> 'This
> could be used as a side channel'.  Notes:  I would hope that any digest
> algorithm used in this capacity was strong enough to obscure whatever
> structure
> was in the plain text.  I would also hope that in this circumstance, an
> Unencoded-Digest field would not be utilized.
>
> This has come up a few times, so happy to (small d) discuss more.
>
> aes128gcm is defined in RFC 8188 and has a section on leaking information
> in header fields [1] . It uses the term "side-channel information". I think
> perhaps we've conflated our terminology a little. If striking the sentence
> is ok by your judgement we can do that, or attempt to use the term
> "side-channel information" to tie it closer to RFC 8118. Please let us know
> if you have a preference.
>
> Similarly, RFC 8188 Section 4.6 also explains how to deal with the
> threats. A blanket SHOULD NOT could be at odds with that advice IMHO. For
> example, one of the mitigations described in RFCF 8188 is to "encapsulate
> the HTTP message using the application/http media type", and in that case
> sending the field within the encapsulation would be ok. Would a statement
> such as the following work?
>
> Old:
>
> > When the "aes128gcm" content coding is used, the security considerations
> in Section 4 of [RFC8188] apply.
>
> > When the "aes128gm" content coding is used, the security considerations
> in Section 4 of [RFC8188] apply. Namely, the Unencoded-Digest is considered
> sensitive information and SHOULD be omitted unless a means of encrypted the
> Unencoded-Digest field is used.
>
>
> Cheers,
> Lucas
>
> [1] - https://www.rfc-editor.org/rfc/rfc8188#section-4.6
>
>
>
>
>
>
>