Subject: [Gen-art] Genart last call review of draft-ietf-core-stateless-05

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Wed, 01 Apr 2020 01:49:46 -0700

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-stateless-05
Reviewer: Dan Romascanu
Review Date: 2020-04-01
IETF LC End Date: 2020-04-02
IESG Telechat date: Not scheduled for a telechat

Summary: READY with Issues.

This is a very clear and well-written document. I have a few minor issues that
I suggest to clarify before approval and publication.

Major issues:

Minor issues:

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

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?

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?

Nits/editorial comments:

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.

2. Are the message formats defined in Appendix A for different transports
considered normative or examples? It would be useful to specify.

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 1 Apr 2020 10:27:51 +0000

> I suggest to clarify before approval and publication.

Many thanks for your review!

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

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

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

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

> 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

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 1 Apr 2020 18:28:22 +0300

Hi Klaus,

Thanks for your quick reply and for addressing the issues raised in my
review.

See below my short comments on a couple of issues.

Regards,

Dan

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

...

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

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 12 Apr 2020 11:31:12 +0200

Dan Romascanu wrote:
> 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.

> I believe that I understood the point that you are making. If I am to suggest text improvements, I would:
>
> - 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

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 12 Apr 2020 13:11:39 +0300

Looks good to me. Thanks for addressing these points.

Regards,

Dan

On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke <[email-masked]> wrote:

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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 23 Apr 2020 16:56:50 -0400

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 <[email-masked]> wrote:
> 
> On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke <[email-masked] <mailto:[email-masked]>> wrote:
> Dan Romascanu wrote:
> >> I'm open to concrete suggestions for text improvements, though..
> >
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art