Re: [core] Genart last call review of draft-ietf-core-stateless-05

[Dan Romascanu <[e-mail]>]

Looks good to me. Thanks for addressing these points.

Regards,

Dan


On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke <[e-mail]> 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
>