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

From: Mališa Vučinić <[email-masked]>
Date: Thu, 20 Jan 2022 18:03:35 +0100

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jan 2022 15:22:09 -0500

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ć <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 20 Jan 2022 21:33:31 +0100

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 <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jan 2022 15:36:13 -0500

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ć <[email-masked]> wrote:
> 
> Russ,
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 20 Jan 2022 21:41:12 +0000

I agree with Russ, and support “sole“ MTI 2/3. 

TNX

Regards,
Uri

> On Jan 20, 2022, at 15:37, Russ Housley <[email-masked]> wrote:
> 
> -- 
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake

---

From: <[email-masked]>
Date: Fri, 21 Jan 2022 07:32:47 +0000

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 <[email-masked]> On Behalf Of Russ Housley
Sent: den 20 januari 2022 21:22
To: Mališa Vučinić <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Russ

> 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:
> 
> 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
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lake__;!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W4f4zZc88K6QeGZ9L6HTKkJ6oR$

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 24 Jan 2022 09:40:44 +0100

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, [email-masked] wrote:
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fissues%2F22&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637783472512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gAVTGJ2evkt7K%2Bo51G%2FSpI4bczj7nBkH4QnKH3lm0m8%3D&amp;reserved=0
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flake&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637783472512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GmsFyRG4gMDkwlfgys2cLh5imW5nVr1PHnAnJk5Iljk%3D&amp;reserved=0
>> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F225%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637783472512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=I0HsePnWLgpIWj05yunrCld0GEhKLLo2AruQs2Hdu7s%3D&amp;reserved=0
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake__%3B!!JmoZiZGBv3RvKRSx!vR_zYuCKuM5OOd8c4klrvqgMTmgbSQ2HVUgsasnpK2W4f4zZc88K6QeGZ9L6HTKkJ6oR%24&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Ce61dce2749624e3bea0708d9dcb045ad%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637783472512429663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1NHNOAoEl0eD6OBqTCiRZzxebC2oMf%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: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Göran Selander <[email-masked]>
Date: Mon, 24 Jan 2022 11:03:48 +0000

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/

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 <[email-masked]> on behalf of Blumenthal, Uri - 0553 - MITLL <[email-masked]>
Date: Thursday, 20 January 2022 at 22:41
To: [email-masked] <[email-masked]>
Cc: Mališa Vučinić <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
I agree with Russ, and support “sole“ MTI 2/3.

TNX

Regards,
Uri

---

From: John Mattsson <[email-masked]>
Date: Mon, 24 Jan 2022 14:55:47 +0000

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 <[email-masked]> on behalf of Göran Selander <goran.selander=[email-masked]>
Date: Monday, 24 January 2022 at 12:04
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>, [email-masked] <[email-masked]>
Cc: Mališa Vučinić <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
Hi Uri,

Göran

TNX

Regards,
Uri

>>>> [1] https://github.com/lake-wg/edhoc/issues/22<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>
>>>> [3] https://github.com/lake-wg/edhoc/pull/225/files<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>
>>>
>>
>
> --
> Lake mailing list
> [email-masked]

---

From: <[email-masked]>
Date: Mon, 24 Jan 2022 15:06:50 +0000

I agree with this.

Best
Peter

From: Lake <[email-masked]> On Behalf Of John Mattsson
Sent: den 24 januari 2022 15:56
To: Göran Selander <goran.selander=[email-masked]>; Blumenthal, Uri - 0553 - MITLL <[email-masked]>; [email-masked]
Cc: Mališa Vučinić <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Hi,

Cheers,
John

From: Lake <[email-masked]<mailto:[email-masked]>> on behalf of Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>
Date: Monday, 24 January 2022 at 12:04
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Mališa Vučinić <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
Hi Uri,

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$>

Göran

From: Lake <[email-masked]<mailto:[email-masked]>> on behalf of Blumenthal, Uri - 0553 - MITLL <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 20 January 2022 at 22:41
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Mališa Vučinić <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Jan 20, 2022, at 3:33 PM, Mališa Vučinić <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Russ,
>>
>>>> On 20 Jan 2022, at 21:22, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> On Jan 20, 2022, at 12:03 PM, Mališa Vučinić <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> [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
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lake<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lake__;!!JmoZiZGBv3RvKRSx!pAivuhagf1Q51Ty6XD_VmJOqKmE8WwuZxBtmEtpBBow0h5l1GSTguaGoAC8UolQYwDYs$>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jan 2022 10:07:06 -0500

Mališa Vučinić <[email-masked]> wrote:
    > 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.

If it differs only in how many bytes are kept of the MAC length,
which means essentially no code differences, but 8 bytes on the wire,
I'd like to ask if we actually need both, period.

    > 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.”

I want to suggest that Constrained endpoints implement:
  (0 xor 1)
  -xor-
  (2 xor 3)

either eat more bytes, or don't.
The device presumably knows what it's Tx power budget needs to be.
Beyond that, it's ECDSA vs EdDSA here, right?

If we wanted a spare suite "in case", then I'd prefer to have Chacha/Poly.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Göran Selander <[email-masked]>
Date: Mon, 24 Jan 2022 18:47:53 +0000

Hi Michael,

We tried to separate SHALL vs SHOULD & ECDSA vs EdDSA (#22) from the MAC length (#209). See inline.

From: Lake <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Monday, 24 January 2022 at 16:08
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

If it differs only in how many bytes are kept of the MAC length,
which means essentially no code differences, but 8 bytes on the wire,
I'd like to ask if we actually need both, period.
[GS:] To comply with the message size requirements we need the one with shorter MAC. Applications that don't have the most extreme size requirements may want to support the longer MAC. So we need to specify both. And as noted in #209 the difference in terms of code to support both is minimal, which is the reason to require implementations to support both when supporting one. If you disagree with that, this is a good time to comment on that issue.

either eat more bytes, or don't.
The device presumably knows what it's Tx power budget needs to be.
Beyond that, it's ECDSA vs EdDSA here, right?
[GS:] In terms of #22 this sounds closer to option 1 than option 2, i.e. to not mandate that all devices implement ECDSA, or that all devices implement EdDSA. Is that a fair summary?
Göran

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jan 2022 18:53:31 -0500

Göran Selander <[email-masked]> wrote:
    GS> To comply with the  message size requirements we need the one with
    GS> shorter MAC. Applications that don't have the most extreme size
    GS> requirements may want to support the longer MAC. So we need to
    GS> specify both. And as noted in #209 the difference in terms of code to
    GS> support both is  minimal, which is the reason to require
    GS> implementations to support both when supporting one. If you disagree
    GS> with that, this is a good time to comment on that issue.

I think you've state things backwards.
I think that the shorter MAC should be the default for all applications that
can tolerate that amount of security.

The question is then, in what situations are the shorter MAC unacceptable, security-wise?
It seems that those devices will know if they need it or not.

    GS> In terms of #22 this sounds closer to option 1 than option 2,
    GS> i.e. to not mandate that all devices implement ECDSA, or that all
    GS> devices implement EdDSA. Is that a fair summary?  Göran

I concur with #22, that option 2 is probably the best MTI.

I don't agree with supporting (0 *and* 1) or (2 *and* 3) on a device.
A device that can afford the extra Tx space for the longer MAC should just use that.
So, if you don't like option 2, then 0.

(PS: I will have to check out of virtual interim early tomorrow)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Jan 2022 00:16:12 +0000

Hiya,

 > (PS: I will have to check out of virtual interim early tomorrow)

Because of the above, I've a question...

> I don't agree with supporting (0*and*  1) or (2*and*  3) on a device.

I'm not clear if that means you can't *live with* the above,
can you clarify?

My reason to ask is that there are a plethora of reasonable
positions on this topic, so I'm not sure we'll land on one
that everyone likes. For me, that means maybe we're better to
try find an imperfect answer with which people can live,
rather than try aim to make everyone very happy.

Ta,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jan 2022 01:34:36 +0100

On 25. Jan 2022, at 01:16, Stephen Farrell <[email-masked]> wrote:
> you can't *live with*

I should probably say that I can’t live with an RFC 6919 “MUST (BUT WE KNOW YOU WON'T)”.

We need to be realistic in our mandates.

"At least one out of 0..3" would be realistic.

(The value of an MTI for a component that goes into other standards before becoming a product is also limited — The MTIs in this case should be in the system standards, not in the component.)

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Jan 2022 00:46:29 +0000

Thanks! Especially for the succinct input - more of that will
help us as chairs try see if there's a rough consensus here.
So I hope others chime in similarly before we meet tomorrow.

S.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 24 Jan 2022 19:53:36 -0500

Hi,

+1 to Carsten's response.

Cheers,
- Ira

On Mon, Jan 24, 2022 at 7:34 PM Carsten Bormann <[email-masked]> wrote:

> (The value of an MTI for a component that goes into other standards before
> becoming a product is also limited — The MTIs in this case should be in the
> system standards, not in the component.)
>
> Grüße, Carsten
>
> --
> Lake mailing list
> [email-masked]

---

From: John Mattsson <[email-masked]>
Date: Tue, 25 Jan 2022 08:24:51 +0000

Hi,

It would be good if the chairs change the title in any slides tomorrow from “MTI cipher suite” to “cipher suite compliance requirements”. MTI cipher suite is just one of the options.

We recently changes the name of the section from “Mandatory-to-Implement Compliance Requirements” to just “Compliance Requirements” as it also contains a lot of “MAY”.

John

From: Lake <[email-masked]> on behalf of Ira McDonald <[email-masked]>
Date: Tuesday, 25 January 2022 at 01:55
To: Carsten Bormann <[email-masked]>, Ira McDonald <[email-masked]>
Cc: Michael Richardson <[email-masked]>, [email-masked] <[email-masked]>, Göran Selander <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
Hi,

Cheers,
- Ira

On Mon, Jan 24, 2022 at 7:34 PM Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Tue, 25 Jan 2022 08:32:32 +0000

Hi Michael, and Chairs

Do we have a potential confusion here?

On 2022-01-25, 00:53, "Michael Richardson" <[email-masked]> wrote:

mcr> I concur with #22, that option 2 is probably the best MTI.

Maybe it is just wording, but I had a problem parsing "option 2 is probably the best MTI" in the context of the chairs' call starting this thread

MV> The options we see at this moment in time are:
MV>
MV> Option 1: Keep current text as-is unless/until more feedback
MV> is provided that motivates re-opening this issue
MV> Option 2: Proceed with selecting a single MTI cipher suite

MV>

MV> We'd like to know if the WG can live with Option 1. Note that
MV> doesn't mean you think option 1 is perfect, just that it's
MV> something with which you can live. If you prefer option 2 or
MV> some other option please suggest specific text.
MV>
MV> Mališa and Stephen

Then I recalled that issue #22 [0] in itself lists different options, where Option 2 means "Keep MTI cipher suite 0."

Are we all talking about the same options?

Göran

[0] https://github.com/lake-wg/edhoc/issues/22

--

---

From: "Claeys, Timothy" <[email-masked]>
Date: Tue, 25 Jan 2022 13:46:01 +0000

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 <[email-masked]> On Behalf Of Marco Tiloca
Sent: Monday, January 24, 2022 9:41 AM
To: [email-masked]
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.

- Contiki-NG: 2
- C-based: 0
- C-based: 2/3
- C-based: 0
- Python-based: 0

Best,
/Marco

On 2022-01-21 08:32, [email-masked] wrote:
>> 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
>> 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
>> 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
> 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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jan 2022 11:01:00 -0500

> I'm not clear if that means you can't *live with* the above, can you
    > clarify?

    > My reason to ask is that there are a plethora of reasonable positions
    > on this topic, so I'm not sure we'll land on one that everyone
    > likes. For me, that means maybe we're better to try find an imperfect
    > answer with which people can live, rather than try aim to make everyone
    > very happy.

I can probably live with almost anything, because RFCs are voluntary :-)

I think that if 0/2 is good enough, then don't do/support 1/3.
What's the point?
There is no security benefit, only coding errors and testing overhead.

If 0/2 is not good enough, then use 1/3.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jan 2022 11:03:11 -0500

> Do we have a potential confusion here?

Could I have read the statements in the issue wrong?  Sure.
(Could your quoting style be more confusing? )

They are issues, not pull requests, so it is hard to know what exactly is
being proposed, vs being discussed.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jan 2022 11:49:02 -0500

Let me go back.

The threat we are dealing with is where an attacker has captured a packet
that they feel does something interesting ("open flood gates now"), or which
they think they know the layout of, and think they can via XOR, flip one of
the plaintext bits by flipping a ciphertext bit.

In order to do that, the attacker has to create a packet that has the same
MAC as the captured packet.  They need some number of extra (irrelevant) bits
which they can permute in order to create such a thing.

Why?

If they knew the authentication/integrity key, they could just create their
own packet, but of course, they might be limited to encrypted packets they
had captured, if they didn't also know the encryption key.
The discussion about 64-bit or 128-bit MACs is how about hard it becomes to
guess a combination that works out.   Fewer bits visible leads to fewer
combinations.  It is unclear to me in such a pre-image attack, if attacker
does not recover the integrity key.   I don't see how they mount such an
attack without it though.

My understanding from the 1990 days of IPsec, and the 96-bit truncated MAC,
was that by truncating it, we open the possibility that when doing this
attack, that the attacker might find a key which leads to the same lower
96-bits, but which isn't actually the correct key.  So one packet works,
but others do not.

A keyed HMAC is very different than a pure pre-image attack on SHAxx.

So what do these extra 8 bytes actually do?

---

From: John Mattsson <[email-masked]>
Date: Wed, 26 Jan 2022 06:45:19 +0000

> So what do these extra 8 bytes actually do?

8 byte tags provide 64-bit security against online brute force attacks. 16 byte tags provides 128-bit security against offline brute force attacks. To break 64-bit security against online brute force an attacker would on average have to send 4.3 billion messages per second for 68 years, which is infeasible in constrained IoT radio technologies. A forgery against a 64-bit MAC in EDHOC breaks the security of all future application data, while a forgery against a 64-bit MAC in the subsequent application protocol (e.g., OSCORE typically only breaks the security of the data in the forged packet.

I don’t understand exactly what attack you are talking about but the following types of attacks has been discussed:

- For most MAC algorithms, a forgery only breaks the security of that single packet and the complexity of key recovery is equal to the key length. For GCM, the complexity of authentication key recovery is equal to the tag length. But the complexities of multi-forgeries for most other MAC algorithms are not well understood.

- If the MAC length is not integrity protected and the receiver accepts different length, an attacker can perform forgeries on 32 bit MAC even if the sender only uses 128 bit MACs.

John

From: Lake <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Tuesday, 25 January 2022 at 17:49
To: [email-masked] <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Let me go back.

Why?

---

From: John Mattsson <[email-masked]>
Date: Wed, 26 Jan 2022 07:04:17 +0000

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 <[email-masked]> on behalf of Mališa Vučinić <[email-masked]>
Date: Thursday, 20 January 2022 at 18:03
To: [email-masked] <[email-masked]>
Subject: [Lake] Ways forward on MTI cipher suite text
Dear all,

Mališa and Stephen

---

From: <[email-masked]>
Date: Wed, 26 Jan 2022 08:49:55 +0000

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 <[email-masked]> On Behalf Of John Mattsson
Sent: den 26 januari 2022 08:04
To: [email-masked]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Hi,

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

Cheers,
John

From: Lake <[email-masked]<mailto:[email-masked]>> on behalf of Mališa Vučinić <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 20 January 2022 at 18:03
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Lake] Ways forward on MTI cipher suite text
Dear all,

John's mail dated 13 May 2021 [2].

We'd like to see if there is rough consensus in the WG on

"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."

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
[email-masked]<mailto:[email-masked]>
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$>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 26 Jan 2022 09:51:00 +0000

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.

I concur.

Hi,

Cheers,

John

Dear all,

Mališa and Stephen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jan 2022 10:35:10 -0500

> 8 byte tags provide 64-bit security against online brute force
    > attacks. 16 byte tags provides 128-bit security against offline brute
    > force attacks.

Brute force attacks against the integrity key, or brute force attacks to
change that specific packet?

    > To break 64-bit security against online brute force an
    > attacker would on average have to send 4.3 billion messages per second
    > for 68 years, which is infeasible in constrained IoT radio
    > technologies.

Agreed, if you are doing an online attack with the responder being your
oracle.   I don't know how to do this in an offline mode because of way that
we use the integrity key.

    > A forgery against a 64-bit MAC in EDHOC breaks the
    > security of all future application data, while a forgery against a
    > 64-bit MAC in the subsequent application protocol (e.g., OSCORE
    > typically only breaks the security of the data in the forged packet.

Agreed.  I'm trying to understand what the extra 8 bytes gives anyone.
I'm just not convinced that it is ever worth it, and that the people who
think that it gives more "security" are not actually thinking things through.

    > - For most MAC algorithms, a forgery only breaks the security of that
    > single packet and the complexity of key recovery is equal to the key
    > length. For GCM, the complexity of authentication key recovery is equal
    > to the tag length. But the complexities of multi-forgeries for most
    > other MAC algorithms are not well understood.

This is the attack I'm talking about.

    > - If the MAC length is not integrity protected and the receiver accepts
    > different length, an attacker can perform forgeries on 32 bit MAC even
    > if the sender only uses 128 bit MACs.

That's silly, that means that the algorithm selection was ignored by the receiver.
Yes, there are people out there who think that receivers will process any
algorithm in the IANA registry.  Really.  I've met them.  It makes a slight
bit of sense when processing *certificates*, but no sense when we have an
AKE.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jan 2022 16:47:55 +0100

> bit of sense when processing *certificates*, but no sense when we have an

In JOSE, we needed to cough up RFC 8725 mostly to make this very point.
Maybe it’s worth to make it in the base document this time.
(Things that are obvious to the authors and the WG but not to the eventual implementer are likely places where protocols develop real life issues.)

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Wed, 26 Jan 2022 16:39:05 +0000

>That's silly, that means that the algorithm selection was ignored by the receiver.

The exist protocols, APIs, and software that do not include the amount of truncation in the algorithm definition. I.e. the algorithm selection SHA-256 means SHA-256 with any truncation, and where the truncation might change. This should not be an issue with COSE implementations.

/John

From: Carsten Bormann <[email-masked]>
Date: Wednesday, 26 January 2022 at 16:48
To: Michael Richardson <[email-masked]>
Cc: John Mattsson <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jan 2022 13:53:00 -0500

Based upon the discussion in this thread, I don't see a reason to include the
longer MAC version.  Certainly not as a MTI, maybe not defined *at all*

At this point, it's just a question of ECDSA vs EdDSA.

I prefer EdDSA going forward, but acknowledge that the current state of
hardware acceleration, library support, and provisioning system preferences
means that ECDSA is here with us for some time.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 26 Jan 2022 18:58:11 +0000

I concur that for real-time traffic shorter MAC should suffice.

I'd prefer ECDSA, considering attacks against EdDSA, especially within the IoT realm.

TNX
--
Regards,
Uri
 
There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 1/26/22, 13:54, "Lake on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: <[email-masked]>
Date: Thu, 27 Jan 2022 08:09:45 +0000

Yes,

For deployments running TSCH with RPL non-storing mode and link layer security a short MAC would be preferable.

Best
Peter

-----Original Message-----
From: Lake <[email-masked]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: den 26 januari 2022 19:58
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

TNX
--
Regards,
Uri

---

From: John Mattsson <[email-masked]>
Date: Sat, 29 Jan 2022 08:23:33 +0000

Note that TLS 1.3 (RFC8446) does not have any mandatory to implement cryptographic algorithms. The Compliance sections (9.1 and 9.2) start with:

“In the absence of an application profile standard specifying
otherwise:”

I think that would be a good formulation for EDHOC as well. Not only for cipher suites but for Section 7 in general.

Cheers,
John

From: Lake <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Thursday, 27 January 2022 at 09:10
To: [email-masked] <[email-masked]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
Yes,

Best
Peter

-----Original Message-----
From: Lake <[email-masked]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: den 26 januari 2022 19:58
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Lake] Ways forward on MTI cipher suite text

TNX
--
Regards,
Uri