[Lake] Re: EDHOC prototyping and feedback

[John Mattsson <[e-mail]>]

>One additional embedding design question I have: is there any technical >benefit or drawback from registering more than one exporter label, as the >OSCORE use does, vs simply use a single label with unique context data?

Security wise they are the same. If you use the same export label, you might want to specify a context format. As an example all TLS-based EAP methods use the same TLS exporter labels and then use the EAP type as context. You could have done this with a single exporter label and context = (type, key).

John

From: Brian Sipos <[e-mail]>
Date: Tuesday, 11 February 2025 at 04:26
To: [e-mail] <[e-mail]>
Subject: [Lake] EDHOC prototyping and feedback
LAKE WG,
I've gone through a trial implementation of EDHOC from RFC 9528 and overall find the definitions in the spec are clear and understandable. The detailed traces from RFC 9529 are also helpful to verify not just self-consistency (being able to establish a session with my own implementation) but absolute correctness against the test states.

During testing I ran into only two intermediate states which were not composed as I had expected from just reading RFC 9528, and the differences were subtle. I think at least one of these represents an errata against the spec as written.

  1.  The composition of PLAINTEXT_2 in section 5.3.2 is defined as a CBOR sequence and the notation used in the ciphertext definition of "PLAINTEXT_2 XOR KEYSTREAM_2" implies that the PLAINTEXT_2 is treated here as a byte string, but when used later in Section 5.4.2 for the transcript hash "H(TH_2, PLAINTEXT_2, CRED_R)" the transcript-being-hashed uses PLAINTEXT_2 not as a byte string value (with a bstr head) but as the sequence itself. I don't think any of the text for either uses is wrong, just apparently unclear enough that my first attempt did treat PLAINTEXT_2 as a bstr item for the transcript hash.
  2.  The compressed encoding of ID_CRED_x used in PLAINTEXT_2 and PLAINTEXT_3, where a KID-only map is compressed to just the KID value, is apparently not used in the construction of internal MAC context_2 and context_3 data. This is not explicitly mentioned either in Section 5.3.2 or 5.4.2 respectively, and I think this does deserve an explicit mention in the spec that the context-encoded ID_CRED_x are different bytes than the plaintext-encoded form of the same structure. This is especially true since it appears that the C_x values do get compressed encoding for the context_x values, so there is some inconsistency. Not to say the spec or traces show incorrect behavior, just that the encoding details deserve explicit discussion in the spec.
Overall I think the function of EDHOC is quite well designed, especially the extensibility via EAD values and the PRK exporter interface. One additional embedding design question I have: is there any technical benefit or drawback from registering more than one exporter label, as the OSCORE use does, vs simply use a single label with unique context data?

Thanks for any and all feedback,
Brian S.