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

[John Mattsson <[e-mail]>]

Hi Carsten,

Thanks for the clarifications regarding 4.2.1, 4.2.2, 4.2.3, and dCBOR. That helped.

>I don’t know where you need to want deterministic encoding for EDHOC

Deterministic encoding is already there. It was added based on feedback from the formal verification, but I don’t think there is a strong security need for it. The biggest win is probably to make clear that 64-bit argument encodings and indefinite-length encodings does not have to be supported.

>> - 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 basic rule is that you take what you get on the wire without re-encoding and things just work. I was thinking that the normative “It is RECOMMENDED to abort the EDHOC session if the received EDHOC message is not encoded using deterministic CBOR” could/should maybe be softened. Forcing implementations to check that received maps are ordered seems complex. I also noted that we are missing clear text on MUST abort if public key validation fails.

OLD:
When parsing a received EDHOC message, implementations MUST abort the
EDHOC session if the message does not comply with the CDDL for that
message.  It is RECOMMENDED to abort the EDHOC session if the
received EDHOC message is not encoded using deterministic CBOR.

NEW:
When parsing a received EDHOC message, implementations MUST abort the
EDHOC session if the message does not comply with the CDDL for that
message. Implementations MAY abort the EDHOC session if the
received EDHOC message is not encoded using deterministic CBOR.
Implementations MUST abort the EDHOC session if validation of a
received public key fails.

Cheers,
John

From: Lake <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Date: Monday, 4 September 2023 at 13:55
To: John Mattsson <john.mattsson=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Lake] Clarifications regarding deterministic CBOR encoding needed?
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


--
Lake mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lake