Change:
It is stated that EDHOC uses deterministic CBOC, but EDHOC could still be non-deterministic if is allows a choice between e.g., bstr and int. Add that the encodig in EDHOC is deterministic. Add some considerations regarding decoding. In any cryptographic protocols the optimal for security is that the decoder raises a fatal error if the something in the encoding is enexpected. E.g. wrong order in map or two byte encoding of the integer 7. This is however not supported by CBOR implementations so it cannot be mandated. The security issues with a allowing decoder is that is gives options to an attacker. If the hash function has some weakness, An attacker can e.g. try all n! permutations of a map with n elements until they find a collision. This is not critical but it might be guidance that a decoder that only tolerated deterministic CBOR might have security benefits.
That would be interesting, notably as it was mentioned as an attack surface previously (). Bellow is an additional example of the kind of weird things that can go on when everything is not nice and deterministic. Consider an attacker that can only modify messages going from Rresponder R to Initiator I, but not send its own messages to R. Then, the identity of R should intuitively be anonymous. This could be the case of an attacker only sitting next to the device I, and who wants to know from whom I is receiving messages. The attacker wants to tests if some I is communicating with some fixed identity . This attacker may intercept the message2 encrypted part: . Now assume that there exists a second distinct encoding of , that we call . The attacker can then compute . Now, two options, either , in which case the message received by I is , which will successfully proceed. If , the processing of the message will fail. And thus, the attacker can learn if I is talking to or not. Remark that in both cases, the key exchange will fail at the next step as parties will disagree on .
Decoding considerations should consider deterministic CBOR, CDDL, and anything outside CBOR and CDDL.
The text about decoding should recommend to abort if encoding not deterministic.
"All EDHOC messages are deterministically encoded CBOR Sequences {{RFC8742}}." Do we need to clarify the meaning of "deterministically encoded CBOR Sequences"? Readers may be lead to believe it is defined in RFC8742.

Discussion:
The EDHOC protocol consists of three mandatory messages (message_1, message_2, message_3) between Initiator and Responder, an optional fourth message (message_4), and an error message.  All EDHOC messages <del> are CBOR Sequences RFC8742. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </del> <ins> are CBOR Sequences RFC8742, and are deterministically encoded. fig- flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </ins> Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the

make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms. <ins> When parsing a received EDHOC message, implementations MUST terminate the protocol if the message does not comply with the CDDL for that message.  It is RECOMMENDED to terminate the protocol if the received EDHOC message is not deterministic CBOR. </ins> 9. 9.1.