- From: Roberto Polli <robipolli@gmail.com>
- Date: Mon, 13 Dec 2021 13:11:14 +0100
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Justin Richer <jricher@mit.edu>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP9qbHVAndYQUfu4636S9naOyFzPw8oyZvPiXAw8y4YpHfh4ew@mail.gmail.com>
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
Received on Monday, 13 December 2021 12:11:39 UTC