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

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

> 
> 
> 
>