[Lake] Pull requests on transporting and encoding connection IDs

[Mališa Vučinić <[e-mail]>]

Hi all,

 

During the interim meeting on Tuesday, we explicitly mentioned two Pull Requests (PRs) that are open in the github pages.

 

PR #117 (https://github.com/lake-wg/edhoc/pull/117) moves the connection IDs (C_I, C_R) from the EDHOC messages to the underlying transport to simplify the specification. The complexity of when to transport which connection IDs is then moved to transport layer, which depending on its correlation properties can decide if omitting different connection IDs makes sense. Practically, the wire format sees the connection ID(s) concatenated with the EDHOC message, but the definitions of EDHOC messages do no longer include the connection IDs. Consequently, connections IDs are no longer cryptographically protected. Message overhead for a given transport remains the same.

 

PR #122 (https://github.com/lake-wg/edhoc/pull/122): Along the lines of PR #117, PR #122 attempts at simplifying the specification by removing the definition of “bstr_identifier”, a special encoding which aims at saving one byte by encoding a CBOR byte string of length 1 in the interval h’00’ to h’2f’ as a single-byte integer. The “bstr_identifier” encoding is currently used for connection IDs and optionally for key ID in ID_CRED. Instead of defining “bstr_identifier”, the PR allows the transport and/or the application using EDHOC to encode these parameters as either integers, and save one byte, or byte strings. When the optimization is used, the complexity of transforming between integers and byte strings is still there, but the decision to use this is now shifted to the applications.

 

We seek feedback on these PRs by June 17th, mailing list or github comments both welcome.

 

Mališa