[core] Review of draft-hartke-core-stateless-01

[John Mattsson <[e-mail]>]

This is very useful and well-written draft that is clearly ready for wg adoption.

I think the use by non-proxy clients need more analysis and guidance. Some comments:

- Should maybe mention that part of the state can be serialized, i.e. something between figure 1 and figure 2

- The mechanism (extended token) and the use case (stateless client) are very entangled. I think it would be good to separate them a little bit more. Some implementations may fit their state in 8 bytes. And maybe some future applications have other use cases for extended token.

- Section 3 talks about integrity protection and freshness. I think the draft also need to talk about replay. Without replay protection, an attacker can easily fool a client (or a proxy in a client role) that it sent more requests than it actually did. Receiving a response can change state or cause other side effects, and receiving several responses to a single request is therefore bad. I do not think this is a problem in the 6tisch use case with proxies, but it becomes a problem when the mechanism is used by non-proxy clients. And if the intermediaries works like firewalls shielding clients from outside traffic, it is a security consideration also for the proxy use case.

- The mechanism can be used to fill the available memory of a proxy, causing DoS, this should be mentioned in the security considerations. I think the draft should also say which Token lengths an implementation supporting this draft needs to support: 65804 bytes or something smaller? Up to the implementation?

- The TODO security considerations should talk about privacy and pervasive monitoring. When used by a proxy, the draft need to discuss that the mechanism may make information (like client IP) available on paths where the information was not available before. If used by a non-proxy client without encryption if can reveal a lot of privacy sensitive information that would otherwise be encrypted.

- I think the encryption requirement (MAY) is too weak. Is there a reason not to encrypt at the same time as integrity protection is done? The encryption requirements should maybe be different for proxy clients and non-proxy clients.

- I think the draft should give developers some recommendation regarding cryptographic algorithms.

Cheers,
John