Re: draft-ietf-httpbis-unencoded-digest-03 ietf last call Secdir review

Hi Rifaat,

Thank you for the review.

On Tue, Jan 13, 2026, at 17:38, Rifaat Shekh-Yusef via Datatracker wrote:
> Document: draft-ietf-httpbis-unencoded-digest
> Title: HTTP Unencoded Digest
> Reviewer: Rifaat Shekh-Yusef
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> The summary of the review is "Ready with Issue"
> 
> Well written document that clearly explains the new mechanism.
> 
> I think the last paragraph of the security consideration section needs a bit more details to 
> describe the implication of using Unencoded-Digest with encrypted content to make it 
> clear how this could lead to leak of information and what could be done to mitigate this risk.

I appreciate this observation. Mallory Knodel made a similar one during the gendir review, and I suggested we wait for a sec opinion.

The intent of the text was to channel the security considerations text in RFC 8188 section 4.6 [1]. Importantly, there are many HTTP fields that could leak information about the encrypted content and RFC 8188 includes some strategies for mitigating the threat, depending on the threat models and user's tolerance. My expectation is that any encrypted content coding has similar security considerations.

Based on the feedback, I'm seeing some actions we can take:

1. Be more precise on what is leaked (the hash of the unencrypted content)
2. Talk specifically about applying RFC 8118 and point directly at its security considerations, placing an onus on implementers to make a decision
3. Make some future looking recommendations similar to RFC 8118's about any other new encrypted content encoding. This one I'm less sure about, because it feels like we risk mitigating on something we don't know and might never come to fruition. Perhaps the best recommendation is that encrypted content codings need to write appropriate security considerations?

I'd appreciate your input and experience here. I plan to prepare some text soon and will circle back with a PR link.

Cheers
Lucas


[1] - https://www.rfc-editor.org/rfc/rfc8188#section-4.6