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

Hi James,

Thanks for the comments. Apologies for the holdup in responding directly,
see in-line responses,we opened up GitHub issues for some of them and links
are provided.


On Thu, Nov 10, 2022 at 8:08 AM Manger, James <
James.H.Manger@team.telstra.com> wrote:

> Comments on draft-ietf-httpbis-digest-headers-10
>
>
>
> 1.
>
> Typo in “2. The Content-Digest Field”: 2nd example should be
> Content-Digest, not Repr-Digest.
>
>
Fixed.

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

See https://github.com/httpwg/http-extensions/issues/2384


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

See https://github.com/httpwg/http-extensions/issues/2385


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

See https://github.com/httpwg/http-extensions/issues/2386


>
> 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.
>
>
>
> If sticking with base64 to display bodies, the “Range: bytes=1-7/18”
> examples would be better as “Range: bytes=3-10/18”. That way you can
> visually recognize that the range (“AItWyFwC/6s=”) is a subset of the
> original (“H4sIAItWyFwC/6tW…”).
>

See https://github.com/httpwg/http-extensions/issues/2387


>
> 6.
>
> No newlines are included at the end of the JSON bodies, though that is
> never mentioned. “Content-Length: 18” on the first {"hello": "world"}
> example could indicate that. Not including newlines is okay for 1-line JSON
> values (even though they have extraneous spaces so they aren’t “compact”
> JSON). No final newline on the multi-line JSON examples is a bit nasty.
>

See https://github.com/httpwg/http-extensions/issues/2388


>
> 7.
>
> Can 2 algorithms have the same preference? For example:
> Want-Repr-Digest: sha-512=5, sha-256=5, unixsum=0
>

See https://github.com/httpwg/http-extensions/issues/2389

Cheers
Lucas