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

To really guarantee interoperability the MTI cipher suite needs to be unambiguous and I think the set should be  minimalistic to account for device constraints.  
I can live with  0/1 OR  2/3. 

Best
Peter

-----Original Message-----
From: Lake <lake-bounces@ietf.org> On Behalf Of Russ Housley
Sent: den 20 januari 2022 21:22
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: lake@ietf.org
Subject: Re: [Lake] Ways forward on MTI cipher suite text

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://urldefense.com/v3/__https://github.com/lake-wg/edhoc/issues/22
> __;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W4f4zZ
> c88K6QeGZ9L6HbSdy47x$ [2] 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lake
> /75nRaD6czYG6RqLT06Qe8C_lsaM/__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4kl
> rvqgMTmgbSQ2HVUgsasnpK2W4f4zZc88K6QeGZ9L6HZMhMsjh$
> [3] 
> https://urldefense.com/v3/__https://github.com/lake-wg/edhoc/pull/225/
> files__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W
> 4f4zZc88K6QeGZ9L6HQ_9_h3C$

--
Lake mailing list
Lake@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W4f4zZc88K6QeGZ9L6HTKkJ6oR$ 