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