Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
Note: This ballot was opened for revision 06 and is now closed.
Murray Kucherawy Yes
Comment (2020-04-12 for -06)
This was very easy to read and understand. Nice work. Editorial stuff: Section 2.2.2: * "... if the server will never be able to handle (e.g., because the token is too large)," -- add "the request" after "handle" * "... a server implementing this document should at least ..." -- s/document/extension/, right? Section 3.1: * "A client SHOULD integrity protect the state ..." -- s/integrity protect/protect the integrity of/ * "Even when the serialized state is integrity protected ..." should be "Even when the integrity of the serialized state is protected ..." * "... the key used for integration protection ..." -- s/integration/integrity/, right? Section 3.3: * "... as a piggybacked response, a separate response or Non-confirmable response, regardless ..." -- comma before "or"
Barry Leiba Yes
Deborah Brungard No Objection
Alissa Cooper No Objection
Roman Danyliw No Objection
Comment (2020-04-21 for -06)
** 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”.
Martin Duke No Objection
Comment (2020-04-23 for -06)
Like everyone else, I enjoyed reading this. But could we paginate the document?
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-11-16 for -07)
Thank you for addressing my Discuss (and Comment!) points.
Erik Kline (was Discuss) No Objection
Warren Kumari No Objection
Comment (2020-04-22 for -06)
Thank you for this, it was a pleasant and easy read (especially as I am not a COAP person). 1: I'd believe that the Abstract needs to say *how* "This document updates RFCs 7252 and 8323." (A simple copy and paste from the start of Section 2 would satisfy this) 2: This is not actionable, but I really really enjoyed the "look ma, no state!" bit in Figure 2. Thank you for keeping documents interesting and fun to read...
Alvaro Retana No Objection
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2020-04-22 for -06)
Thank you for the work put into this document. The document is clear, easy to read and quite useful. The security aspects are also well defined. Please find below a single non-blocking COMMENT. An answer will be appreciated. I hope that this helps to improve the document, Regards, -éric -- Section 2.1 -- Why does this document update RFC 8323 definition of TKL? At first sight, the TKL field definitions in this document and in RFC 8323 look identical.
Magnus Westerlund No Objection
Robert Wilton No Objection
Comment (2020-04-20 for -06)
Thanks for this document. I found the document easy to read and the concept described easy to understand. A few minor comments: 2.1 Extended Token Length (TKL) Field 13: An 8-bit unsigned integer precedes the Token field and indicates the length of the Token field minus 13. 14: A 16-bit unsigned integer in network byte order precedes the Token field and indicates the length of the Token field minus 269. I wonder whether it would be worth changing "precedes" to "directly precedes" to avoid any doubt of exactly where the length field appears? Although I note that the updated message formats are in the appendix anyway. 2.2.1. Extended-Token-Length Capability Option The draft doesn't suggest whether the Extended-Token-Length capability option should be used when the server only supports a max-length of 8. Would it be useful to give a recommendation for servers in this case, e.g. SHOULD they only include the capability if they support a max token length larger than 8 bytes? 3. Stateless Clients As servers are just expected to return any token verbatim to the client, this implementation strategy for clients does impact the interoperability of client and server implementations. However, there are a number of significant, non-obvious implications (e.g., related to security and other CoAP protocol features) that client implementations need take into consideration. I found the first sentence somewhat unclear - in that I was wondering if "does not impact" was intended instead of "does impact"? Or otherwise, I wasn't quite sure what this sentence was trying to convey.