Dan, thanks for your reviews. Klaus, thanks for your responses. I entered a No Objection ballot.
Alissa > On Apr 12, 2020, at 6:11 AM, Dan Romascanu <droma...@gmail.com> wrote: > > Looks good to me. Thanks for addressing these points. > > Regards, > > Dan > > > On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke <har...@projectcool.de > <mailto:har...@projectcool.de>> wrote: > Dan Romascanu wrote: > >> > 1. It would be useful to include some considerations whether the authors > >> > consider useful / possible / allowed that the mechanism (extended token > >> > lengths) presented in this document can be used for other purposed than > >> > the by-design the use case (avoiding per-request state). > >> > >> The last paragraph in Section 1 says: > >> > >> While the use case (avoiding per-request state) and the mechanism > >> (extended token lengths) presented in this document are closely > >> related, both can be used independently of each other: Some > >> implementations may be able to fit their state in just 8 bytes; some > >> implementations may have other use cases for extended token lengths. > >> > >> Does that solve your issue? > > > > Actually this is exactly the paragraph that triggered my concern. Does > > 'using independently' mean that you encourage or do not care > > implementations in the future dealing with other use cases? If the answer > > is yes, maybe the current text is fine. If the answer is 'rather not' than > > a discussion would be welcome. > > The paragraph is intended to give permission that extended token > lengths may be used for other purposes than avoiding per-request > state. Of course, these will need security considerations etc., but > those are out of this document's scope. > > >> > > The use of encryption, integrity protection, and replay protection of > >> > serialized state is recommended in general, unless a careful analysis > >> > of any potential attacks to security and privacy is performed. AES- > >> > CCM with a 64 bit tag is recommended, combined with a sequence number > >> > and a replay window. Where encryption is not needed, HMAC-SHA-256, > >> > combined with a sequence number and a replay window, may be used. > >> > > >> > A few issues with this paragraph. Why are not 'recommended' and 'may' > >> > capitalized? The formulation 'is recommended in general' seems odd, and > >> > the rest of the sentence does not clarify. What does 'a careful analysis > >> > of any > >> > potential attacks' mean? Who is supposed to perform this analysis and who > >> > can ensure it is 'careful enough' at any given point in time for any > >> > potential > >> > attacks? > >> > >> AFAIK, the Security Considerations section is supposed to discuss > >> security-related issues that users need to be aware of, but not make > >> normative statements. So all the normative requirements are in Section > >> 3.1. (Where 'users' in this case are implementations and specifications > >> that decide to make use of this implementation strategy in clients.) > >> > >> Overall, it's a bit difficult to make normative requirements here, because > >> these are usually about the interoperability e.g. of a client and a > >> server. But in this case, the client only needs to interoperate with > >> itself (it needs to accept a token that it created itself) and the only > >> real requirement is that "client implementations MUST NOT be vulnerable to > >> maliciously crafted tokens". The meaning of "vulnerable" and "malicious" > >> here depends a lot on the application/deployment-specific context; the > >> document can really just highlight some potential issues that users should > >> take into consideration. > >> > >> I'm open to concrete suggestions for text improvements, though.. > > > > I believe that I understood the point that you are making. If I am to > > suggest text improvements, I would: > > > > - s/recommended in general/recommended/ > > - clarify, maybe in this very words that "the requirement is that client > > implementations must not be vulnerable to maliciously crafted tokens" > > I've made these two changes in the Security Considerations section and > also tried to improve clarity in section 3.1. I will submit a -06 > shortly. > > Thanks! > > Klaus > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
