- From: Deb Cooley via Datatracker <noreply@ietf.org>
- Date: Sun, 29 Mar 2026 05:16:34 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-unencoded-digest@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Deb Cooley has entered the following ballot position for draft-ietf-httpbis-unencoded-digest-04: No Record 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.
Received on Sunday, 29 March 2026 12:16:38 UTC