Re: [Lake] Ways forward on MTI cipher suite text

Russ Housley <housley@vigilsec.com> Thu, 20 January 2022 20:22 UTC

Return-Path: <housley@vigilsec.com>
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 BBBA83A1F6F for <lake@ietfa.amsl.com>; Thu, 20 Jan 2022 12:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2a1cCcNT5a9k for <lake@ietfa.amsl.com>; Thu, 20 Jan 2022 12:22:11 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 A1EC13A1949 for <lake@ietf.org>; Thu, 20 Jan 2022 12:22:11 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 3567613F2BD; Thu, 20 Jan 2022 15:22:10 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 29F0B13F46A; Thu, 20 Jan 2022 15:22:10 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <2A2081E4-BAAF-4292-925E-0B683AA6CD23@inria.fr>
Date: Thu, 20 Jan 2022 15:22:09 -0500
Cc: lake@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8E1F91B-FEEB-44E9-B87F-1F0767123523@vigilsec.com>
References: <2A2081E4-BAAF-4292-925E-0B683AA6CD23@inria.fr>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/Fgk025xICf7NgjyPJ4i71Z1JPFg>
Subject: Re: [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 20:22:16 -0000

I would prefer to see one MTI (Option 2).  I can live with that MIT being 0/1 or 2/3, and I have a mild preference for 2/3.

Russ


> On Jan 20, 2022, at 12:03 PM, Mališa Vučinić <malisa.vucinic@inria.fr> wrote:
> 
> 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