Dan Romascanu wrote:
> This is a very clear and well-written document. I have a few minor issues that
> I suggest to clarify before approval and publication.
Many thanks for your review!
> 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?
> 2. In Section 2.2:
>
> > The idea is that a server implementing
> this document should at least support large tokens in its first
> few processing steps, enough to return an error response rather
> than a Reset message.
>
> Why is not this 'should' capitalized? What happens if the server does not
> support large tokens in the first processing steps?
If the server does not support large tokens in the first processing steps, it
will likely incorrectly indicate that extended token lengths are not supported
at all. This is what the 'MUST NOT' in the preceding paragraph prevents:
If a server supports extended token lengths but receives a request
with a token of a length it is unwilling or unable to handle, it MUST
NOT reject the message, as that would imply that extended token
lengths are not supported at all.
The design note provides just additional commentary on this 'MUST NOT'; it
doesn't add any new requirements.
> 3. In Section 5.2:
>
> > 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.
> 1. I do not believe there is a need to mention in the Abstract that 'This
> document updates RFCs 7252 and 8323.'. This is shown in the header of the
> text on the front page, and also is part of the metadata.
Without, idnits reports:
-- The draft header indicates that this document updates RFC7252, but the
abstract doesn't seem to mention this, which it should.
-- The draft header indicates that this document updates RFC8323, but the
abstract doesn't seem to mention this, which it should.
> 2. Are the message formats defined in Appendix A for different transports
> considered normative or examples? It would be useful to specify.
Section 2.1 normatively defines the new message formats as a "delta" to RFCs
7252 and 8323. The appendix shows the result of applying that "delta". So, both
are just different ways to present the same normative information. I'll add a
sentence clarifying that.
Best regards,
Klaus
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
