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

I agree with this.

Best
Peter

From: Lake <lake-bounces@ietf.org> On Behalf Of John Mattsson
Sent: den 24 januari 2022 15:56
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>; Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>; lake@ietf.org
Cc: Mališa Vučinić <malisa.vucinic@inria.fr>; Russ Housley <housley@vigilsec.com>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Hi,

I think the most important thing is that this MTI discussion does not take up too much time. It would be good to get this over with. I can live with both options. If we go with option 2. the only viable choice seems to be 2/3, which seems to be the most common in current implementations.

- As I said before I think a MTI cipher suite does not improve interop much. The cipher suite is just one of many parameters needed for interop.

- If we go for option 2. I think the the MTI requirement should be on the software implementation and possible to disable when compiling for a specific device. Constrained IoT is different from non-constrained TLS/IPsec in that closed ecosystems are very common and that supporting several different algorithms on a device might not be feasible due to storage limitations. Closed ecosystems with devices using 0, 1, 24, or 25 should not be forced to use storage for 2/3 that is never used. There are existing implementation of 0, 1, and 24.

Cheers,
John

From: Lake <lake-bounces@ietf.org<mailto:lake-bounces@ietf.org>> on behalf of Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org<mailto:goran.selander=40ericsson.com@dmarc.ietf.org>>
Date: Monday, 24 January 2022 at 12:04
To: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu<mailto:uri@ll.mit.edu>>, lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Cc: Mališa Vučinić <malisa.vucinic@inria.fr<mailto:malisa.vucinic@inria.fr>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
Hi Uri,

Just to see if I understand your comment, I compared your recent response with the mail from December:

https://mailarchive.ietf.org/arch/msg/lake/1ifhkgxtqIHgt2AuQ6UMytkbY-o/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lake/1ifhkgxtqIHgt2AuQ6UMytkbY-o/__;!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UovJn_L4n$>

I thought Option 1, i.e. having recommended by not MTI cipher suites, matched the position in the referenced email better.  Maybe I misunderstood something?

Göran

From: Lake <lake-bounces@ietf.org<mailto:lake-bounces@ietf.org>> on behalf of Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu<mailto:uri@ll.mit.edu>>
Date: Thursday, 20 January 2022 at 22:41
To: lake@ietf.org<mailto:lake@ietf.org> <lake@ietf.org<mailto:lake@ietf.org>>
Cc: Mališa Vučinić <malisa.vucinic@inria.fr<mailto:malisa.vucinic@inria.fr>>, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
I agree with Russ, and support “sole“ MTI 2/3.

TNX

Regards,
Uri

> On Jan 20, 2022, at 15:37, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:
>
> Selecting one MTI provides the broadest possible interoperability.  I think it would be harmful at this stage to divide the implementers into 0/1 and 2/3.
>
> Russ
>
>> On Jan 20, 2022, at 3:33 PM, Mališa Vučinić <malisa.vucinic@inria.fr<mailto:malisa.vucinic@inria.fr>> wrote:
>>
>> Russ,
>>
>> Thanks for your feedback. Could you state any technical arguments why do you believe that would be the best way forward?
>>
>> Mališa
>>
>>>> On 20 Jan 2022, at 21:22, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:
>>>
>>> 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<mailto: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<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ff26b0af930d12f4&q=1&e=2f7b2843-fdd9-4462-98d5-2e3b1dea8354&u=https*3A*2F*2Fgithub.com*2Flake-wg*2Fedhoc*2Fissues*2F22__;JSUlJSUlJQ!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UopVCpboA$>
>>>> [2] https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/__;!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UokTCVKbO$>
>>>> [3] https://github.com/lake-wg/edhoc/pull/225/files<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9795506a0cfc96b8&q=1&e=2f7b2843-fdd9-4462-98d5-2e3b1dea8354&u=https*3A*2F*2Fgithub.com*2Flake-wg*2Fedhoc*2Fpull*2F225*2Ffiles__;JSUlJSUlJSU!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UokeLwENb$>
>>>
>>
>
> --
> Lake mailing list
> Lake@ietf.org<mailto:Lake@ietf.org>
> https://www.ietf.org/mailman/listinfo/lake<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lake__;!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UolQYwDYs$>