[Lake] EDHOC prototyping and feedback

[Brian Sipos <[e-mail]>]

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.