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

Hi Lucas,

See my replies below.

Regards,
 Rifaat


On Tue, Jan 13, 2026 at 1:23 PM Lucas Pardue <lucas@lucaspardue.com> wrote:

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

How about the following:
An attacker that gets access to the hash header field can infer details
about the unencrypted content without decrypting it, if, for example, the
message has a predictable pattern.


> 2. Talk specifically about applying RFC 8118 and point directly at its
> security considerations, placing an onus on implementers to make a decision
>

I am assuming you meant to point to RFC 8188 (not RFC 8118).

Ideally, you do not want to defer security decisions to implementers.
If that is not possible, at least provide clear guidance on when to use
this mechanism and when to avoid it.

I skimmed through RFC 8188, which seems to provide a detailed security
consideration section.
I agree that referring the implementer to that RFC is a good idea.



> 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 am, again, assuming you meant to point to RFC 8188 (not RFC 8118).
I do not think that you need to say anything about potential future
encryption, because any future documents that define different encryptions
will have to provide security considerations anyway. Or did I miss
understand this comment?

Regards,
 Rifaat




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