[Lake] Ways forward on MTI cipher suite text

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 20 January 2022 17:03 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 F39873A1914 for <lake@ietfa.amsl.com>; Thu, 20 Jan 2022 09:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level:
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 U320SzaglD2h for <lake@ietfa.amsl.com>; Thu, 20 Jan 2022 09:03:42 -0800 (PST)
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 039153A1915 for <lake@ietf.org>; Thu, 20 Jan 2022 09:03:40 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.88,302,1635199200"; d="scan'208";a="17088388"
Received: from adsl-lns3-l3730.crnagora.net (HELO smtpclient.apple) ([77.222.14.146]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2022 18:03:37 +0100
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Message-Id: <2A2081E4-BAAF-4292-925E-0B683AA6CD23@inria.fr>
Date: Thu, 20 Jan 2022 18:03:35 +0100
To: lake@ietf.org
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/jds-fD2YvI4l-tiK0EvAFjzta8M>
Subject: [Lake] Ways forward on MTI cipher suite text
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, 20 Jan 2022 17:03:45 -0000

Dear all,

During the last LAKE interim meeting, we discussed the issue
of an MTI cipher suite and we agreed for the chairs to open a
thread on the subject. As a reminder, the previous discussion
points on this topic are summarized in github [1] and in
John’s mail dated 13 May 2021 [2].

We’d like to see if there is rough consensus in the WG on
this topic, at this moment in time. Knowing that the formal
analysis of the EDHOC-12 specification is under way, we
should keep in mind that additional input may arrive down the
road from teams working in the computational model.

As a reminder, the most recently discussed text for this
is in a PR [3] and states:

“For many constrained IoT devices it is problematic to support several crypto primitives. Existing devices can be expected to support either ECDSA or EdDSA. Cipher suites 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference. Similarly for cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-16-64-128, SHA-256). To enable as much interoperability as possible, less constrained devices SHOULD implement all four cipher suites 0-3. Constrained endpoints SHOULD implement cipher suites 0 and 1, or cipher suites 2 and 3. Implementations only need to implement the algorithms needed for their supported methods.”

The options we see at this moment in time are:

Option 1: Keep current text as-is unless/until more feedback
is provided that motivates re-opening this issue
Option 2: Proceed with selecting a single MTI cipher suite

We'd like to know if the WG can live with Option 1. Note that
doesn't mean you think option 1 is perfect, just that it's
something with which you can live. If you prefer option 2 or
some other option please suggest specific text.

Mališa and Stephen

[1] https://github.com/lake-wg/edhoc/issues/22
[2] https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/
[3] https://github.com/lake-wg/edhoc/pull/225/files