Draft: draft-ietf-lake-edhoc

Commentary: 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 . that the encodig in EDHOC is deterministic . 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 can not 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 ( ) .  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 .
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.