Re: Publication has been requested for draft-ietf-httpbis-digest-headers-10

On 10.11.2022 09:06, Manger, James wrote:
> Comments on draft-ietf-httpbis-digest-headers-10
>
> 1.
>
> Typo in “2. The Content-Digest Field”: 2^nd example should be
> Content-Digest, not Repr-Digest.
>
> 2.
>
> In “6.5 Usage with Encryption” it isn’t clear what layer of encryption
> is assumed (representation, content). I guess it is assuming a
> Content-Encoding that encrypts, such as “Content-Encoding: aes128gcm”
> from RFC 8188. And the security consideration is pointing out that if
> the encryption is performed multiple times to respond to multiple HTTP
> requests then the ciphertext (& hence Content-Digest & Repr-Digest) is
> likely to change each time, as each encryption (of the same plaintext)
> is likely to use a different nonce and/or key.
>
> This issue could occur without encryption. For instance, compression
> algorithms often have different “levels” (eg 1=fast, 9=best). So the
> representation could change if the level changed between requests. Maybe
> that will be rare enough to ignore?
>
> I thought “6.5 Usage with Encryption” might be warning against including
> a digest of the plaintext if encryption was applied as, say, a
> transfer-encoding (not sure if there are encrypting transfer-encodings).
> That would be insecure.
>
> 3.
>
> There are no examples of any of the 6 “insecure” algorithms that are
> still listed in the table. This is particularly important as checksums
> were conveyed in decimal and hex in Digest, but will now be
> base64-encoded in Content-Digest & Repr-Digest. Do you base64-encode the
> decimal digits from, say, cksum; or base64-encode the 32-bits (most
> significant byte first?) they represent?
>
> 4.
>
> “/entries/1234” is used in appendix A while “/items/123” is used in
> appendix B, even though they seem to be for the same resources (without
> & with …-Digest headers).
>
> 5.
>
> Base64-encoding non-printable bodies so they can be included in the
> document is unfortunate. Particularly as there are lots of “real” base64
> values (ie all the …-Digest values). Perhaps hex would have been better
> to display bodies.
> ...

FWIW, I'm planning to define a "hexdump" Content-Encoding, solely for
the use in spec examples. But that wouldn't help here, due to
publication timing.

Best regards, Julian

Received on Thursday, 10 November 2022 08:14:14 UTC