[core] Roman Danyliw's No Objection on draft-ietf-core-stateless-06: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-core-stateless-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-stateless/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** I support Ben Kaduk’s DISCUSS position that the SHOULDs in Section 3.1 would
likely be better described as MUSTs.  Additionally, I would recommend,
threading this guidance with Section 3.3. and 5.2.  Specifically:

-- Section 3.3.  Per “If a piggybacked response passes the token integrity
protection and freshness checks …” and “If a separate response passes the token
integrity protection and freshness checks …”, where is the guidance for these
checks described?  Is that the language in Section 3.1?

-- Section 5.2.  Per “The use of encryption, integrity protection, and replay
protection of serialized state is recommended …”, why not “RECOMMENDED”?  How
does this text line with the conditions outlined in Section 3.1?

-- Section 5.2.  Per “AES-CCM  with a 64 bit tag is recommended …”, why not
“RECOMMENDED?”

** Section 5.2.  Please provide a citation for AES-CCM and HMAC-SHA-256.

** Section 5.2. Recommend describing the consequences of not using security
services.  Perhaps something on the order of:

OLD:
   The use of encryption, integrity protection, and replay protection of
   serialized state is recommended , unless a careful analysis of any
   potential attacks to security and privacy is performed.

NEW
The use of encryption, integrity protection, and replay protection of
serialized state is recommended, unless a careful analysis of any potential
attacks to security and privacy is performed.  In the absence of integrity and
reply protection, an on-path attacker or rogue server/intermediary could return
a state (either one modified in a reply, or an unsolicited one) that could
alter the internal state of the client stack.

** Editorial nit:
-- Figure 2 and 5.  I would recommend replacing the colloquialism “look ma, no
state!” with “no state”.