[Lake] Pull requests on transporting and encoding connection IDs

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 03 June 2021 09:35 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3729A3A31B5 for <lake@ietfa.amsl.com>; Thu, 3 Jun 2021 02:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY6yvHz2qYoc for <lake@ietfa.amsl.com>; Thu, 3 Jun 2021 02:35:42 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7B53A31B3 for <lake@ietf.org>; Thu, 3 Jun 2021 02:35:41 -0700 (PDT)
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AwClbD6gpP/DNGEUo9wcR+gjY43BQXu8ji2hC?= =?us-ascii?q?6mlwRA09TyX+rbHNoB17726RtN91YhodcL+7Sc+9qAznmKKdjbNxAV7aZmbbUQ?= =?us-ascii?q?iTXeRfBPXZrQEIcheWntK16Z0BT0EUMqyWMbEVt6zHCFnRKadC/PC3tL+pnvrD?= =?us-ascii?q?x3IoaTxDApsN0ztE?=
X-IronPort-AV: E=Sophos;i="5.83,244,1616454000"; d="scan'208,217";a="511461257"
Received: from clt-128-93-179-158.vpn.inria.fr (HELO [128.93.179.158]) ([128.93.179.158]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 03 Jun 2021 11:35:39 +0200
User-Agent: Microsoft-MacOutlook/10.11.0.180909
Date: Thu, 03 Jun 2021 11:35:36 +0200
From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= <malisa.vucinic@inria.fr>
To: "lake@ietf.org" <lake@ietf.org>
Message-ID: <B27AD0E3-680A-485D-9A3B-208D41CC0378@inria.fr>
Thread-Topic: Pull requests on transporting and encoding connection IDs
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3705564939_395718772"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/AYKn1CvXizcP9xFEFVUb9vl5Ags>
Subject: [Lake] Pull requests on transporting and encoding connection IDs
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 09:35:46 -0000

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