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

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.

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.

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

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.

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

--
James Manger



General