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

[[e-mail]]

I have had a preference to EdDSA, but In light of presentation from Rene I don't think it is reasonable to make EdDSA an MTI.



Best
Peter



From: Lake <[e-mail]> On Behalf Of John Mattsson
Sent: den 26 januari 2022 08:04
To: [e-mail]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Hi,

I noticed to nobody has argued for EdDSA in the recent discussion. One potential way forward would maybe be to reformulate the current text without cipher suites 0 and 1. There has been several people expressing that they want the requirement to implement one or more cipher suite to be stronger. This would lead to Option 3 below.

- Option 3: Remove cipher suites 0 and 1 from the current text. Reformulate according to current discussion. Make implementation requirements for cipher suite 0 and 1 stronger for some types of implementations such as maybe less constrained devices, software libraries, non-closed deployments....

People typically have strong opinions on details. It is sometimes easier to agree on nothing. Option 4 below would align with what COSE is doing.

- Option 4: Just remove current text and replace it with nothing.

(I ignored the "2, 3, or 2 and 3" issue above, that also need to be discussed)

Cheers,
John


From: Lake <[e-mail]<mailto:[e-mail]>> on behalf of Mališa Vučinić <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 20 January 2022 at 18:03
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Lake] Ways forward on MTI cipher suite text
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:/github.com/lake-wg/edhoc/issues/22__;!!JmoZiZGBv3RvKRSx!oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjtmwJiui$>
[2] https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/__;!!JmoZiZGBv3RvKRSx!oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjmVyYhuw$>
[3] https://github.com/lake-wg/edhoc/pull/225/files<https://urldefense.com/v3/__https:/github.com/lake-wg/edhoc/pull/225/files__;!!JmoZiZGBv3RvKRSx!oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjjrL_38v$>


--
Lake mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lake<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lake__;!!JmoZiZGBv3RvKRSx!oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjtnfowyW$>