W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: draft-ietf-httpbis-digest-headers-11, "6.3. Usage in Signatures"

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 17 Mar 2023 23:15:41 +0000
Message-ID: <CALGR9oZhH2oNPLGZmVB6s0yUP_k6NMngJOweCLOXOpKJyymUKQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Julian,

On Sun, 12 Mar 2023, 13:13 Julian Reschke, <julian.reschke@gmx.de> wrote:

> Hi there,
>
>  > Signatures are likely to be deemed an adversarial setting when
> applying Integrity fields; see Section 5. Using signatures to protect
> the checksum of an empty representation allows receiving endpoints to
> detect if an eventual payload has been stripped or added.
>
> I understand the case where a representation was *added* (where
> previously it was empty). But the opposite case?
>

Thanks for raising this. IIRC I think the intention was to describe a
scenario where signatures are used with digest and that either a) there is
nothing to send, so use the empty representation digest (helping to spot
addition) b) there is something to send, so send the digest of that and
then if the payload gets stripped, the receiver can detect the digest
doesn't match that of an empty representation and then bail.

Arguably in case b, stripping could be detected by implementing a naive
check like "no data, no digest to calculate,  so fail without calculation"
but I _think_ we wanted to highlight that some implementation could compare
the received digest to that of the empty digest.

I admit the text doesn't paint this out as well as it could. Do my
explanations make more sense? I can make an editorial PR along these lines
if so.

Cheers
Lucas
Received on Friday, 17 March 2023 23:16:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 March 2023 23:16:05 UTC