Subject: [Lake] Pull requests on transporting and encoding connection IDs

From: Mališa Vučinić <[email-masked]>
Date: Thu, 03 Jun 2021 11:35:36 +0200

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

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 04 Jun 2021 11:09:42 +0200

Just a quick clarification on my summary of PR #117 in its state as of today: the PR does cryptographically protect the connection IDs, as (mandatory) IDs are still transported within the EDHOC messages and so included in the transcript hash, while the optional ones are left out for the transport to handle depending on the correlation properties. See github link for further discussion.

Mališa

From: Lake <[email-masked]> on behalf of Mališa Vučinić <[email-masked]>
Date: Thursday 3 June 2021 at 11:35
To: "[email-masked]" <[email-masked]>
Subject: [Lake] Pull requests on transporting and encoding connection IDs

Hi all,

Mališa

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