Re: [Lake] Clarifications regarding deterministic CBOR encoding needed?

[Carsten Bormann <[e-mail]>]

Hi John,

I’m not sure I understand all of this (I don’t know where you need to want deterministic encoding for EDHOC), but here is my quick feedback before I go on vacation:

> On 2023-09-04, at 10:02, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> 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.

4.2.2 discusses deteriministic encoding of Tags and floating point values, as well as some application considerations for these.  I don’t think these are relevant for EDHOC.  4.2.3 is a legacy variant that indeed should not be used.
So referring to 4.2.1 is what you need if you want deterministic encoding for EDHOC.
The dCBOR proposal is some entirely different and not relevant here.

> - Deterministic CBOR encoding affects all integers and all maps. Maps occur in ID_CRED_x and CRED_x.

(Not just integers, also arguments for strings, arrays and maps.)

> - I note that there is no normative RFC2119 terms to use deterministic CBOR, but there is a SHOULD abort. This is a bit strange.

If you need deterministic encoding for correctness (like, e.g., COSE does for its signing inputs), this needs to be a MUST.

> - 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.

Deterministic encoding is useful if you compute a serialized data item from some other data and want all participants to arrive at the same serialized bytes before, e.g., signing/checking a signature.

> - 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.

I’m not sure I understand this case.  Does a kid identify a CCS in a serialized form, or do you deserialize/serialize before using the CCS for some crypto operation?  In the latter case, you probably need deterministic encoding, but you also have to take care of CCS-specific serialization decisions (e.g., int or float for timestamps/NumericDate).

If CCS needs to be deterministically encoded and NumericDate can be floating point values, you need Section 4.2.2 Bullet 2 Item 2.

https://www.ietf.org/archive/id/draft-bormann-cbor-det-01.html
…is a backgrounder on deterministic encoding, and Section 2 of
https://www.ietf.org/archive/id/draft-bormann-cbor-dcbor-03.html#name-common-cbor-deterministic-e
…actually is not about dCBOR, but about a common way to make decisions about deterministic encoding beyond Section 4.2.1 of RFC 8949.

Grüße, Carsten