Last Call Review of draft-ietf-core-stateless-05
review-ietf-core-stateless-05-genart-lc-romascanu-2020-04-01-00

Request Review of draft-ietf-core-stateless
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-04-02
Requested 2020-03-12
Authors Klaus Hartke, Michael Richardson
Draft last updated 2020-04-01
Completed reviews Secdir Last Call review of -05 by David Mandelberg (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Secdir Telechat review of -06 by David Mandelberg (diff)
Genart Telechat review of -06 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-core-stateless-05-genart-lc-romascanu-2020-04-01
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/zZ2uU2tTC2X3gC1KYZ5ZP5S_tFA
Reviewed rev. 05 (document currently at 08)
Review result Ready with Issues
Review completed: 2020-04-01

Review
review-ietf-core-stateless-05-genart-lc-romascanu-2020-04-01

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.