Comments on Encryption from Achim

[emanjon]

https://mailarchive.ietf.org/arch/msg/core/BOG6xkClHS29vlQqUYaQBwZkB58/

I appreciate the added statement about encryption in the abstract. Does the

"Several of the discussed attacks can be mitigated with the solutions in RFC 9175."

require the combination with encryption in order to mitigate the attacks? I think so.

Overall, I'm wondering, if the preconditions of such attacks could be documented clearer?

E.g. assuming an "on-path-attacker" RFC 9175 without encryption may be in vain.

A couple of attacks assume, that tokens are reused frequently. In my experience, that's not the case (except in cases, where someone stick to (re-)use the empty token to save bandwidth, or reuse tokens for testing/debugging). Different tokens and replay-windows are then creating also protection in a couple of cases.

With a list of preconditions it would be easier to see, if a system is affected by that attack or not.

You added "availability", but I miss the see an example, if there is a specific risk using coap.

[emanjon]

The commit ee4cb90 addresses most of this issue. Remains to clearer document preconditions for attacks.

[emanjon]

A couple of attacks assume, that tokens are reused frequently. In my experience, that's not the case (except in cases, where someone stick to (re-)use the empty token to save bandwidth, or reuse tokens for testing/debugging). Different tokens and replay-windows are then creating also protection in a couple of cases.

Might differ between implementations. Might have been more common in early implementations. I think (re-)using the empty token to save bandwidth has been quite common. Some people thought that was one of the best things in CoAP. Some CoAP libraries let's the application provide the token.

From a security perspective I dont think "not done frequently" cut it at all. Nothing wrong with DTLS, but the initial coaps specification allows reuse is a fundamental design flaw equal to if DTLS would reuse its sequence numbers. Somebody of the security analysis was lost when moving from HTTP over TLS to CoAP over DTLS. Luckily it is quite easily fixed.

We should make it clear that the attacks refers to unpached coaps implementations. If the updated Token rules are used none of the problems in the remains at all.

[emanjon]

With a list of preconditions it would be easier to see, if a system is affected by that attack or not.

Yes, lets try to document that better

[emanjon]

Fixed in recent commits to master. Complete changes can be seen in the diff