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

["Claeys, Timothy" <[e-mail]>]

Hi all

Sorry for the late reply. I also tend to prefer option 1 (text-as-is). If it is decided that we need to select either 0/1 or 2/3 as MTI then my preference goes to 2/3.

Best regards,
Timothy

-----Original Message-----
From: Lake <[e-mail]> On Behalf Of Marco Tiloca
Sent: Monday, January 24, 2022 9:41 AM
To: [e-mail]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Hi all,

Personally I can live with Option 1 (current PR text as-is) and still tend to prefer it. I basically agree with the first sentence from the quoted text on which the following normative part builds, I believe pragmatically.

I also agree with what was pointed out at the 2021-12-15 interim
meeting: implementors on constrained platforms would do what they want/can with what they have, thus making it difficult to avoid a practical risk of non interoperability altogether. For some, supporting a particular MTI cipher suite might not be practically affordable at least for some time.

While my non-constrained implementation for Californium has supported cipher suites 0/1/2/3 basically from the beginning, I remember of different supports from the implementations that took part to interop tests last year.

Just to recap, tested implementations supported the following cipher suites:

- Contiki-NG: 2
- C-based: 0
- C-based: 2/3
- C-based: 0
- Python-based: 0
- Python-based: 0/1/2 (I guess also 3, but not tested)
- Java-based: 0/1/2/3

Best,
/Marco

On 2022-01-21 08:32, [e-mail] wrote:
> 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 <[e-mail]> On Behalf Of Russ Housley
> Sent: den 20 januari 2022 21:22
> To: Mališa Vučinić <[e-mail]>
> Cc: [e-mail]
> 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ć <[e-mail]> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fiss
>> ues%2F22&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea
>> 0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637783472
>> 512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
>> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gAVTGJ2evkt7K%2Bo51G
>> %2FSpI4bczj7nBkH4QnKH3lm0m8%3D&amp;reserved=0
>> __;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W4f4z
>> Z
>> c88K6QeGZ9L6HbSdy47x$ [2]
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%
>> 2Flake&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea07
>> 08d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63778347251
>> 2429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GmsFyRG4gMDkwlfgys2cLh
>> 5imW5nVr1PHnAnJk5Iljk%3D&amp;reserved=0
>> /75nRaD6czYG6RqLT06Qe8C_lsaM/__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4k
>> l rvqgMTmgbSQ2HVUgsasnpK2W4f4zZc88K6QeGZ9L6HZMhMsjh$
>> [3]
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpul
>> l%2F225%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3b
>> ea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6377834
>> 72512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=I0HsePnWLgpIWj05yu
>> nrCld0GEhKLLo2AruQs2Hdu7s%3D&amp;reserved=0
>> files__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2
>> W
>> 4f4zZc88K6QeGZ9L6HQ_9_h3C$
> --
> Lake mailing list
> [e-mail]
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F
> lake__%3B!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2
> W4f4zZc88K6QeGZ9L6HTKkJ6oR%24&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%
> 7Ce61dce2749624e3bea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%
> 7C0%7C0%7C637783472512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1NH
> NOAoEl0eD6OBqTCiRZzxebC2oMf%2FQJa0%2FyF6%2FVkw%3D&amp;reserved=0

--
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

This message is subject to the following terms and conditions: MAIL DISCLAIMER<https://www.barco.com/en/maildisclaimer>