[Lake] Clarifications regarding deterministic CBOR encoding needed?

[John Mattsson <[e-mail]>]

Hi,

While working on invalid test vectors with the implementors it has been suggested by Marco that explicit reminders about deterministic CBOR should be added in e.g., 3.5.3 of the EDHOC specification. I agree that this is a good idea.

Background:

- Section 1.4 states
"When referring to CBOR, this specification always refers to Deterministically Encoded CBOR as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]."
- Section 3.1 states
"All EDHOC messages are CBOR Sequences [RFC8742], and are deterministically encoded."
- Section 3.5.2 states
"If for some reason re-encoding of the authentication credential may
occur, then a potential common encoding for CBOR based credentials is
bytewise lexicographic order of their deterministic encodings as
specified in Section 4.2.1 of [RFC8949]."
- Section 9 states
"It is RECOMMENDED to abort the EDHOC session if the
received EDHOC message is not encoded using deterministic CBOR."


Some notes and thoughts:

- The sentence in 3.1 should be changed to "encoded using deterministic encoded CBOR as specified in Section 4.2.1 of [RFC8949]." With randomized algorithms, EDHOC is not deterministic.
- I don't think 4.2.2 of [RFC8949] is relevant for EDHOC. I suggest only refering to 4.2.1. Stating that 4.2.2. is not relevant and that 4.2.3 shall not be used. dCBOR is not references and not needed here.
- Deterministic CBOR encoding affects all integers and all maps. Maps occur in ID_CRED_x and CRED_x.
- I note that there is no normative RFC2119 terms to use deterministic CBOR, but there is a SHOULD abort. This is a bit strange.
- The reason deterministic CBOR was introduces was to limit an attackers possibilities in the case the hash funtion has weaknesses. Does deterministic encoding cause implementation complexity? Not sure it makes sense to mandate if the ECDSA signatures are randomized anyway.
- It is not clear when a CCS is deterministicly encoded. That should be fixed. My understanding is
- EDHOC does not mandate deterministic encoding of the kccs value
- When receiving a kccs the kccs value is used as CRED_x without reencoding.
- When identifying a CCS with a kid and there is risk for different encodings, both sides need to encode deterministically.

Happy with any thought, feedback, and suggestions on this topic.

Cheers,
John