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

[Klaus Hartke <[e-mail]>]

Hi John,

thanks a lot for the review!

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

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

Added at the end of section 1:

   While the mechanism (extended token lengths) and the use case
   (stateless clients) presented in this document are closely related,
   both can be used independently of the other: Some implementations may
   fit their state in 8 bytes; some implementations may have other use
   cases for extended token lengths.

> - Section 3 talks about integrity protection and freshness.

I thought the term "freshness" would imply that. Could you provide
some text to clarify the paragraph?

> - 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 idea in the interim call yesterday was along the lines of: A node
in client role needs to support token lengths up to the maximum length
of the tokens it sends; the supported token length for a node in
server role is up to the implementation. If the serialized state fits
in this implementation limit, it works; otherwise, there's probably
not much the node in client role can do anyway to make the state
smaller, so it fails.

Should there be a mandatory-to-implement minimum length, e.g., 24 bytes?

I think there needs to be a requirement that the node in server cannot
change its maximum supported length at will (e.g., when it runs out of
memory), because that would make discovery of support unreliable.

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

Contributions are welcome!

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

WOULD PROBABLY [1]? :)

More seriously: Since this is not an interoperability issue, I'm not
sure how much we can require here in general. More input on this would
be great.

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

This is not an interoperability issue. But giving some implementation
guidance might be helpful indeed. What algorithm should be
recommended?

Klaus

[1] https://tools.ietf.org/html/rfc6919