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

[Russ Housley <[e-mail]>]

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ć <[e-mail]> 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 <[e-mail]> 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ć <[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://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
>> 
>