Subject: [secdir] secdir review of draft-ietf-core-stateless-05

From: David Mandelberg <[email-masked]>
Date: Sun, 15 Mar 2020 13:03:33 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is ready with issues.

I think this protocol change increases the amount of data that a CoAP 
server would reflect in a DoS attack using spoofed source IP addresses 
with UDP. I don't see any opportunity for amplification though, just 
reflection of more data sent by a malicious client. I'm very much not a 
DoS expert though, so I have no idea if this is an issue at all.

What happens when a client changes the (implementation-private) format 
of the state it puts in the tokens? E.g., what if a client sends a 
request, applies a software update, then receives the response? (I'm 
guessing that's a more likely situation with UDP, since the software 
update would probably interrupt a TCP session.) If an attacker can 
predict when the software update will happen and how the new version 
will interpret the old version's tokens, can they replay anything 
maliciously? (Assuming the replay window includes some messages from 
just before the software update.)

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 17 Mar 2020 15:38:07 +0000

David Mandelberg wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.

Thanks a lot!

> I think this protocol change increases the amount of data that a CoAP server
> would reflect in a DoS attack using spoofed source IP addresses with UDP. I
> don't see any opportunity for amplification though, just reflection of more
> data sent by a malicious client. I'm very much not a DoS expert though, so I
> have no idea if this is an issue at all.

Right, the amount of data that can potentially be reflected increases. The CoAP RFC already has a section on reflection and amplification [1]; I will add an explicit reference to that section to the draft.

> What happens when a client changes the (implementation-private) format of
> the state it puts in the tokens? E.g., what if a client sends a request, applies a
> software update, then receives the response? (I'm guessing that's a more
> likely situation with UDP, since the software update would probably interrupt
> a TCP session.) If an attacker can predict when the software update will
> happen and how the new version will interpret the old version's tokens, can
> they replay anything maliciously? (Assuming the replay window includes
> some messages from just before the software update.)

Right, false interoperability with previous implementation versions might cause a security issue. I will add a paragraph along these lines to the draft ("...SHOULD include a version indicator in the serialized state...").

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-11.3

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Mar 2020 17:17:39 +0100

> Right, false interoperability with previous implementation versions might cause a security issue. I will add a paragraph along these lines to the draft ("...SHOULD include a version indicator in th…

Not sure that a "version indicator” is a SHOULD, but including something that changes when the interpretation of the data is changed, is.

(I’m sure anyone familiar with CSRF tokens will have put that in, already.)

Grüße, Carsten