Subject: [core] Review of draft-ietf-core-stateless-01

From: Thomas Fossati <[email-masked]>
Date: Thu, 27 Jun 2019 06:40:22 +0000

Hi Klaus,

(Focusing solely on the security aspects of the protocol.)

Section 4.1:

   A node in the server role supporting extended token lengths may be
   vulnerable to a denial-of-service when an attacker (either on-path or
   a malicious client) sends large tokens to fill up the memory of the
   node.  Implementations MUST be prepared for this and mitigate it.

I'm having a bit of trouble making sense of this last sentence:

1. It doesn't provide helpful advice on how to "prepare for" and/or
   "mitigate";

2. The "MUST be prepared" part looks like a quality of implementation
   remark rather than an interop requirement that requires BCP14
   language.

I suggest to remove the MUST from "prepare for" and explain practically
what that means, e.g.: "Implementations should define a local upper
bound for the token size that is configurable based on the node's
available physical memory."  Then explain what "mitigate" means in
protocol terms, e.g.: "Requests exceeding this limit MUST be rejected
with status 4.XX, responses exceeding this limit MUST be silently
discarded.", or similar.

Section 4.2:

   Transporting the state needed by a client to process a response as
   serialized state information in the token has several significant and
   non-obvious security and privacy implications that need to be
   mitigated.

Maybe s/mitigate/addressed/ ? But overall this paragraph doesn't seem to
add much: I suggest to drop it altogether and start this section straight
from the second para.

   Serialized state information is an attractive target for both
   unwanted nodes (attackers between the node in client role and the
   next hop) and wanted nodes (the next hop itself) on the path.

This distinction between wanted/unwanted sounds a bit funny, besides the
terms are defined here but never used in the remainder.  My suggestion
would be to remove them and instead say something like: "Serialized
state information is an attractive target for both relaying nodes and
passive observers."

   Therefore, a node in the client role MUST integrity protect the state
   information, unless processing a response does not modify state or
   cause other significant side effects.

   [...] Therefore, the node in client role MUST
   implement replay protection (e.g., by using sequence numbers and a
   replay window), unless processing a response does not modify state or
   cause other significant side effects.

   If processing a response without keeping request state is sensitive
   to the time elapsed to sending the request, then the serialized state
   MUST include freshness information (e.g., a timestamp).

( s/to sending/from sending/ ? )

   Information in the serialized state may be privacy sensitive.  A node
   in client role MUST encrypt the serialized state if it contains
   privacy sensitive information that an attacker would not get
   otherwise.

I'm slightly concerned by all these "MUST unless, MUST if" as they seem
to leave too much discretion in the hands of the application using CoAP.

Taking a slightly higher perspective on the stateless approach, ISTM
that to get on par with "usual" CoAP tokens, the serialised state MUST
be auth-encrypted and replay-protected always.  I am conscious that the
typical user of stateless wants to avoid committing extra resources in
the first place, however using stateless without these safeguards looks
like trading some efficiency increase with a significant decrease in
security, robustness & privacy, which also happens to downgrade the
established CoAP/application contract.  Vice versa, by requiring
auth-encryption & replay protection all the obvious attacks on security
dissolve (*) and we are back to known, safe territory.  Privacy-wise
there is still a problem related to leaking message size, which we could
suggest mitigating with padding.

(*) Except maybe for the confusion attack involving an on-path active
attacker who can swap tokens between two (or more) outstanding requests
from the same node, maybe in combination with suppressing one (or more)
responses.  However, I guess this is not really different from what you
can already do with NoSec CoAP, and if this is a material threat then
what you really need is a secure transport to complement the secured
token (because you don't want to trust the proxy with your clear-text
serialised state anyway.)

   [...]  In wireless mesh networks,
   where all traffic is visible to a passive attacker, encryption may
   not be needed as the attacker can get the same information from
   analyzing the traffic flows.

I must really be missing something big because I fail to understand why
communicating over a wireless mesh makes token encryption redundant?

A final question: as an after-effect in case integrity/encryption keys
are persisted, can an Observation survive the reboot of the node?  If
so, it's maybe worth pointing that out explicitly as it may or may not
be a desirable thing?

Cheers, thanks!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.