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

Mališa Vučinić <> Fri, 04 June 2021 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E77E3A3014 for <>; Fri, 4 Jun 2021 02:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nHQTeNzuohw0 for <>; Fri, 4 Jun 2021 02:09:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41BDA3A300E for <>; Fri, 4 Jun 2021 02:09:47 -0700 (PDT)
IronPort-HdrOrdr: A9a23:zKDdCK7RqTNsXvrJEgPXwL3XdLJyesId70hD6qkfc3Bom6Cj+vxG4s506facsl94M03I8uruBEDvexnhyaI=
X-IronPort-AV: E=Sophos;i="5.83,248,1616454000"; d="scan'208,217";a="511684260"
Received: from (HELO []) ([]) by with ESMTP/TLS/AES256-GCM-SHA384; 04 Jun 2021 11:09:45 +0200
User-Agent: Microsoft-MacOutlook/
Date: Fri, 04 Jun 2021 11:09:42 +0200
From: Mališa Vučinić <>
To: "" <>
Message-ID: <>
Thread-Topic: [Lake] Pull requests on transporting and encoding connection IDs
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3705649785_1980571700"
Archived-At: <>
Subject: Re: [Lake] Pull requests on transporting and encoding connection IDs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2021 09:09:55 -0000

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.




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


Hi all,


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


PR #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 ( 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.




-- Lake mailing list