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

[John Mattsson <[e-mail]>]

Hi Klaus,

To new comments:

- Note that to fulfill the updated requirements on Token processing in Section 5 of draft-ietf-core-echo-request-tag-02, clients cannot be stateless, or the extended token must have a large enough random part. I think Section 5 of draft-ietf-core-echo-request-tag and draft-hartke-core-stateless would benefit from being discussed together. If draft-hartke-core-stateless is working group adopted, it might make sense to move the updated token processing from draft-ietf-core-echo-request-tag to draft-hartke-core-stateless.

- The use case of stateless proxies is requested by 6tisch and is reasonable simple to analyze from a security and privacy perspective. The use case of stateless non-proxy client is from a security and privacy perspective a completely different and much more complicated beast (the token contains the whole privacy sensitive request (+ maybe internal state) and replay must be mitigated). As 6tisch needs this draft ASAP, I think it might be best to remove the use case of "stateless" non-proxy clients and focus on the extended token mechanism and the use case of "stateless" proxies.

More comments inline 

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

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

I think what you want so to say for "stateless" non-proxy clients is that the mechanism used to produce the tokens MUST protect against replay. Note that this means that 100 % "stateless" is not possible. For proxy clients, I do not know if you always need replay protection. I do not know if freshness (in the sense that the time period between sending the request and receiving the response is small) is needed. I can help by providing text, but less discuss what it needed first.

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

This is exactly what I was looking for. I think this should be added to the draft. But I still think that the security considerations should discuss that the mechanism can be used to fill the available memory of a proxy, causing DoS.

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

I am fine with " up to the implementation" if that is what you agreed.

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

Is the alternative, i.e. just rejecting requests any better?

>>- 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 can help by providing text, but less discuss what it needed first.

>> - 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]? :)

:) For non-proxy clients, this stateless use case basically means that the client puts the whole request (+ maybe some internal state) in the token. If the client uses (D)TLS or OSCORE to protect requests. I think the requirement needs to be SHALL/MUST encrypt.

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

As this is a security/privacy/pervasive monitoring there is no problem to have SHALL/MUST even if it is not an interoperability issue. In fact, RFC 7258 says that workings groups need to mitigate pervasive monitoring when possible.

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

For a non-proxy client, I think AES_CCM with a 64 bit tag could be recommended. For a proxy client that does not need encryption, HMAC-SHA-256 could be recommended.




-----Original Message-----
From: Klaus Hartke <[e-mail]>
Date: Thursday, 11 October 2018 at 14:29
To: John Mattsson <[e-mail]>
Cc: "[e-mail] WG" <[e-mail]>
Subject: Re: [core] Review of draft-hartke-core-stateless-01

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