Re: Working Group Last Call: Digest Fields

Thanks Justin,

this a very good and indeep revision! Thanks Justin for all the time that
you spent in
reviewing this document!
I just reply to the issues not already addressed by Lucas,
with which I agree.

Il giorno sab 11 dic 2021 alle ore 04:16 Lucas Pardue <
lucaspardue.24.7@gmail.com> ha scritto:
>> It bothers me that the draft doesn't use structured fields,
> I think if we want to pursue structured digests further, we should just
admit that changing the world is hard and define new fields.
I agree with Lucas. We tried to accommodate in many ways, but with no
success :(

> If requests need some special considerations that we do not cover, then
I'm open to additions of that sort
Agree, could you please file a PR on that?


>> §1.3: it seems like this document is going for both semantic and
syntactic compatibility of existing fields and definitions, right? The text
currently says semantic only.
> Agreed, see https://github.com/httpwg/http-extensions/issues/1840
Has PR


> Maybe someone has a smart, salient way to describe representation and
content in this draft in a way we don't already cover?
iirc we were explicitly suggested to avoid invading the space of other
specifications.

I think we can't reasonably do more than
https://www.ietf.org/archive/id/draft-ietf-httpbis-digest-headers-07.html#appendix-A-6
since this is also covered in SEMANTICS (eg.
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#partial.PUT)
which is the ultimate
source for that.

>> §7: ... the Digest header in a request would actually be a digest of the
**resource that is being requested**.
>> Is that the intent? Because if so, that seems completely insane to me,
and I wouldn't know how to process that, so I hope I'm wrong.
I can't read that explicitly... Where do you read this behavior?

>> My expectation with requests, including all state-changing requests, is
that it's the message content of **the request itself** that is hashed for
the digest.
>> So if I do a POST, I digest the body and add the header. If I do a PUT,
same deal.
>> Like in the example, if I do a PATCH, I digest only the part that I
send, not the "whole" thing that's being represented -- or is that only for
Content-Digest?
>> I'm honestly not sure.
@Justin Richer this section is heavily dependent on:
-
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-6.4
-
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-6.4.2
The point is that Digest, differently from Content-Digest, is associated to
the resource and not to the content.

For example, in cases described in
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#partial.PUT
the request Digest should be computed on the completed, reconstructed
representation and not on the
request content. This will be useful to ensure that the server
reconstructed the intended resource correctly
and is consistent with implementations such as
https://docs.microsoft.com/en-us/rest/api/storageservices/put-range
and enable the server to know in advance if the final checksum is correct.

>> But for GET, I would expect that Digest would not be allowed because
there's no body to digest.
imho it's legitimate to send a GET with a Digest/Content-Digest of an empty
content.
In RFC3230 there's nothing that forbids sending Digest with a specific
method.


>> §8: Additional security consideration: Bad encoding to break parsers.
For example, sending bad base64 in an attempt to break or crash the parser,
which is needed to validate the digest.

> Interesting. Can I ask a bit more about the threat model you have in mind
here? Do you have any examples of such attacks? I'm not opposed to
addressing genuine concerns but I don't fully understand the scope of the
problem in relation to Digest headers. To put it another way, what is it
about Digest that makes header parsing failure worse than any other header
field?

>> §8.2: I don't see how this is a security consideration except for the
last line, which is mostly punted to §8.3.
>> Consider rewriting this portion to be about the actual security gap, and
not a list of the spec's virtues and applications.
Has PR

>> This could probably be covered by §8.1 and §8.3 anyway, but if there's
enough to say in its own section, then focus on what's different and
discussed here.
>>
>> §8.3: Surprised not to see a reference to httpbis-message-signatures in
here. :)
>>
>> §8.3: You SHOULD NOT use normative requirements in the security
considerations.
Has PR

 >> The first line needs to be its own security consideration referencing
BCP19 for TLS usage, the second can go into §6 probably, with back and
forward references.
Has PR

> ... Signatures should state how Digest is used, not the other way
around...
>>  ...simply highlighting the limitations of digest (it doesn't cover HTTP
fields) and then noting that there's a way to encode the digest of an empty
representation that can be used by signature to protect from some types of
manipulation.
> There seems nothing unique in Digest that requires this property when
compared to other HTTP fields.
Has PR

>> §8.5: The fact that you could digest an unencrypted payload then send it
encrypted genuinely surprised me -- I would not have thought that possible
within the content-encoding mechanisms of HTTP. I think this is going to be
a combination that leads to many errors.
Has PR See https://github.com/httpwg/http-extensions/issues/1839
>
>> §8.6: This draft's algorithm agility effectively allows an attacker to
choose and substitute the algorithm applied to the message,
>  Thanks. See https://github.com/httpwg/http-extensions/issues/1841
>
>>
>> §8.7: Structured field dictionaries disallow the same key in a
dictionary, so couldn't we just say that repeating a key is simply an
error?
Already discussed. While I supported Justin view, It was decided not to
change the current syntax.

>> §XX: The document is missing privacy considerations. This RFC provides
good guidelines for writing them:
https://datatracker.ietf.org/doc/html/rfc6973
> Do you have any specific concerns for the fields defined in this document
that you feel need to be addressed by privacy considerations? The last 7
RFCs that this group produced did not include a privacy considerations
@Justin Richer <jricher@mit.edu> Feel free to propose.


>> §9.2: Is normative text allowed in such a description here?
> I don't think we can make an IANA table entry normative for anything :-)
Tracked in https://github.com/httpwg/http-extensions/issues/1842
Good spot!

>> §A: This section is missing examples of how the Digest and
Content-Digest headers would be applied to each of these messages.
>> I know that's also the goal of the next section, but it seems out of
place separated from each other.
>> I also realize that the entire point of having something like §A is
because of people like me who still have problems wrapping their heads
around this topic. :)
> I'm 50/50 on this....
> A candidate PR might help the debate.
See   https://github.com/httpwg/http-extensions/issues/1843
>
>> §B: ... neither of these are "resources" or "files" in the traditional
HTTP or REST model.

Mumble ..iirc  in http, user-agents and origin servers exchange resource
representations.

> In appendix B.6 we show a client sending a JSON object and a server
responding with a brotli encoded JSON.
> ... From a cursory glance, it's just POST method and request and response
content of JSON.

Exactly

Thanks again,
R.

> [1] - https://github.com/httpwg/http-extensions/issues/1671
> [2] - https://www.rfc-editor.org/rfc/rfc8941.html#name-byte-sequences
> [3] -
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-14.2
> [4] -
https://www.ietf.org/archive/id/draft-nottingham-http-structure-retrofit-00.html