Subject: [Lake] Ambiguous text on Mandatory to Implement suite

From: Mališa Vučinić <[email-masked]>
Date: Thu, 16 Dec 2021 10:19:23 +0100

All,

(chair hat off)

As discussed during the interim yesterday, the current text in -12 on MTI requirements (Section 7) reads as follows:

>    For many constrained IoT devices it is problematic to support more
>    than one cipher suite.  Existing devices can be expected to support
>    either ECDSA or EdDSA.  To enable as much interoperability as we can
>    reasonably achieve, less constrained devices SHOULD implement both
>    cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-
>    CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-
>    256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256).  Constrained
>    endpoints SHOULD implement cipher suite 0 or cipher suite 2.
>    Implementations only need to implement the algorithms needed for
>    their supported methods.

I see two issues here: 1) imprecise language; 2) normative text that implies interoperability only in case when both peers implement both suites 0 and 2.

When it comes to the devices and their capabilities, we have so far been using the precisely defined terms from RFC 7228. This is not the case here and we use terms such as “less constrained devices”, “constrained endpoints”. This is all very confusing. Why endpoint and not device? What does “less constrained device” actually mean in terms of RFC 7228?

Assuming that the “constrained endpoint” is a typo and instead means “constrained device”, the normative statement in this text, i.e. implementing 0 OR 2, implies that we can achieve interoperability only in the case when both peers implement both 0 and 2 cipher suites. Requiring the implementation of two cipher suites on each device to achieve interoperability is far from the lightweight aspect of LAKE, so I would like to hear what are the working group’s thoughts on this.

Mališa

---

From: Göran Selander <[email-masked]>
Date: Thu, 16 Dec 2021 10:44:44 +0000

Hi Mališa,

This mail is not responding to your questions below, more a comment about process.

I was surprised to have this discussion in the meeting yesterday since the intent was to talk about Stefan's proposal (issue #209) and not the overall MTI topic (issue #22), for which John had started another mail thread:

https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/

As Carsten pointed out the issues are orthogonal. If the WG decides on "MUST implement cipher suite 2" on #22, we would also mandate cipher suite 3 if we follow the proposal in #209. (If anyone disagrees to that, please post in #209.)

I think it would be good if people who have an opinion on the topic responds to John's mail which summarizes the previous discussion well. There is also a proposal for procedure to come to a decision at the end to his mail. Whatever procedure we take it would be great if the chairs would announce in advance to allow those who have a strong opinion to take part in the thread and the decision.

Göran

From: Lake <[email-masked]> on behalf of Mališa Vučinić <[email-masked]>
Date: Thursday, 16 December 2021 at 10:19
To: [email-masked] <[email-masked]>
Subject: [Lake] Ambiguous text on Mandatory to Implement suite
All,

(chair hat off)

Mališa

--
Lake mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=1&e=ad041382-e3a6-40b4-a5f3-15ae63819e02&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 16 Dec 2021 12:59:54 +0000

Speaking of MTI suites – I’d like to see at least one offering 256-bit level of security.

--

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

From: Lake <[email-masked]> on behalf of Göran Selander <goran.selander=[email-masked]>
Date: Thursday, December 16, 2021 at 05:46
To: Mališa Vučinić <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

Hi Mališa,

Göran

All,

(chair hat off)

Mališa

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 16 Dec 2021 14:27:27 +0100

Hi Goran,

My email was not a process-related email, thus the hats off disclaimer. I suppose we should make out of it another complimentary issue and just make sure that we have clear language in the spec.

Mališa

> On 16 Dec 2021, at 11:44, Göran Selander <[email-masked]> wrote:
> 
> Hi Mališa,
>  
> https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/ <https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/>
>  
> [email-masked] <mailto:[email-masked]>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=1&e=ad041382-e3a6-40b4-a5f3-15ae63819e02&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=1&e=ad041382-e3a6-40b4-a5f3-15ae63819e02&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake>

---

From: Rene Struik <[email-masked]>
Date: Thu, 16 Dec 2021 10:23:20 -0500

Hi Malisa:

If one has to implement both Suites #0 and #2, one has to implement both 
SHA-512 and SHA-256 (since EdDSA uses SHA-512 under the hood).

I still do believe EdDSA is insecure in the environments this WG is 
targeting and should be ditched. How can one still possibly defend 
including a deterministic signature scheme in a specification that 
clearly contravenes the stability and side-channel resistance 
stipulations for MTI algorithms of BCP 201/RFC 7696, despite dozens of 
publications about trivial implementation attacks? Please also see my 
email of  a year ago, Dec 18, 2020, on Guidance on MTI algorithms [1].

It is too bad that nobody ever pursued attempts to rectify this (such as 
in 
https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/, 
originally suggested two years ago, on Dec 17, 2019). Pretending that 
the issue is going away is without action is, however, not credible. {Of 
course, one could still try and stick an RFC 8032 label on something 
that isn't, but I wonder whether IETF would then devalue to simply a 
marketing label issuing body, where an external shadow spec would have 
to redefine things to make specs work. }

Currently, the only secure signature scheme that uses Curve25519 under 
the hood is ECDSA25519, as specified in the lwig curve document [2]. 
This scheme also uses SHA256 as hash function, thereby obviating the 
need to implement two hash functions if one were to have to implement 
both the "NIST" suite and another one.

Side question: whatever happened with the suggestion in John Mattson's 
Feb 11, 2021 email re including ECDSA25519 in the formal analysis [3]?

Ref:
[1]https://mailarchive.ietf.org/arch/msg/lake/_sy7LSHk8idGAV_408JQOafi6LQ/
[2] 
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-22#section-4.3
[3] https://mailarchive.ietf.org/arch/msg/lake/UYaV56yxz_zUWOqU32SoVozSw4I/

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 16 Dec 2021 16:43:40 +0100

Uri,

Cipher suites 24 and 25 are intended to be for high-security applications [1]. Could you comment if these do not meet your needs? 

[1] https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-9.2 <https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-9.2>

Mališa

> On 16 Dec 2021, at 13:59, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 16 Dec 2021 16:38:31 +0000

Yes I can, and yes they do. 

My only concern/wish is having one of them (say, 24) as MTI - as opposed to merely “defined”.

Thanks

Regards,
Uri

> On Dec 16, 2021, at 10:44, Mališa Vučinić <[email-masked]> wrote:
> 
> Uri,
> 
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-9.2
> 
> Mališa
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2021 18:09:19 +0100

> My only concern/wish is having one of them (say, 24) as MTI - as opposed to merely “defined”.

Mandatory to implement as in “MUST (BUT WE KNOW YOU WON'T)” (RFC 6919)?
I don’t think a lot of very constrained systems will go for this.

Or do you want (0&1) | (2&3) | (24|25) ?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Dec 2021 14:00:39 -0500

> I don’t think a lot of very constrained systems will go for this.

Ditto.
I think that we need to replace the "MTI" concept for constrained systems.

Fundamentally, it's not about strength, it's about:
1) encouraging some defense programming in the face of algorithm agility
2) being able to switch algorithms on relatively short notice

(Moving from AES128 to AES256 is not necessarily useful if AES* turned out to
be thing which is flawed)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 17 Dec 2021 20:22:45 +0000

> > I don’t think a lot of very constrained systems will go for this.

What alternative do you suggest? Don't say "MUST" at all, since you don't expect "a lot of systems" to comply  anyway?

> I think that we need to replace the "MTI" concept for constrained systems.

Respectfully disagree. 

MTI is about guarantee (to a reasonable degree) of interoperability between implementations/products.

> Fundamentally, it's not about strength, it's about:

Actually, it *is* about strength. Though yes, your other two points also matter. 

> 1) encouraging some defense programming in the face of algorithm agility

Already (being) done, with _very_ variable degree of success.

> 2) being able to switch algorithms on relatively short notice

Yeah... It's not your friendly desktop Web browser, y'know... Peter Gutman can probably tell you much more about SCADA and embedded devices, how frequently they "switch algorithms", and how short those notices are...

Let's be realistic here, please. Especially since you don't think that (even) requiring to implement stronger cipher-suites would be honored by the implementers.

> (Moving from AES128 to AES256 is not necessarily useful if AES* turned
> out to be thing which is flawed)

My bet is that AES* won't "turn out to be the thing...", but you're missing my point - for some applications AES128 is not acceptable to begin with.

Oh, on the AES128 vs. AES256 conversation: if you care to know, Russian GOST 28147-89 block cipher (released, as you can guess, in 1989) had 256-bit key. Go figure.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2021 23:04:44 +0100

> MTI is about guarantee (to a reasonable degree) of interoperability between implementations/products.

This concept is very useful for standards that essentially establish a plug-and-play environment.

A standard like EDHOC which is a component in a larger environment does not necessarily need its own plug-and-play; this should come from the system standards where it is embedded.
(Well, maybe unless the decision is a slam-dunk, which apparently it is not in this case.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Dec 2021 17:49:34 -0500

> My bet is that AES* won't "turn out to be the thing...", but you're
    > missing my point - for some applications AES128 is not acceptable to
    > begin with.

Not missing your point.
Some ecosystem where AES128 is not strong enough will need AES256 (or GOST).

In such an ecosystem, not only would AES128 be forbidden by policy, it might
even be that it needs to be removed from the code base so that it can't be
used by mistake.  That goes entirely against what is normally intended by MTI.
(MTI does not equal mandatory to use, which is often missed by people outside
the IETF, btw.  Some think that if it's in the IANA table that it can be
used)

As Carsten says, EDHOC will be used in a bigger profile, and that profile
will need to decide what we need.  IPsec did a good job of making this
suggestion clearer as to what to implement, but IPsec has never (alas!!!!),
experienced random two nodes on the Internet use.

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

---

From: John Mattsson <[email-masked]>
Date: Sat, 18 Dec 2021 12:23:29 +0000

Hi,

My two cents:

- Interoperability: I don't understand this focus on MTI cipher suite and interoperability. EDHOC works mostly like COSE where different applications and deployments can choose from a smorgasbord of options to optimize what fits their specific environment. I think this approach has been very successful for COSE. Two implementations will not be interoperable unless they implement the same:

  -  1. Transport protocol
  -  2. EDHOC method (0, 1, 2, 3, ......)
  -  3. ID_CRED_R COSE header parameter (kid, kid_context, x5t, x5chain, x5bag, x5u, kcwt, kcct, c5u, c5t, c5b, c5c, ....)
  -  4. CRED_R COSE credential type (CWT, CCS, X.509, C509, ..... ) with a matching credential profile.
  -  5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, EAD_4)
  -  6. Identifier used as identity of endpoint
  -  7. If message_4 shall be sent/expected
  -  8. Subsequent application protocol
  -  9. Data sent over the subsequent application protocol
  - 10. Cipher suite.

Implementing the same cipher suite is just a quite small piece in interoperability between two endpoints.

- Having a MTI cipher suite has significant drawbacks. TLS 1.2 mandates support of TLS_RSA_WITH_AES_128_CBC_SHA. This cipher suite has at least 3 major weaknesses: static RSA, CBC padding attacks, and SHA1. Each one of these weaknesses could independently warrant a must not support. This causes a lot of problems, as many industries are very keen on compliance with standards. With TLS 1.2 an implementation can be either compliant or weak. I personally think the IPsec approach is better: "The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves.". I don't see any reason to force local IoT deployments wanting to use EdDSA + X25519 or the CNSA cipher suite to also implement cipher suite 0. I can live with something like the current proposal from Stephen, but my personal preference would be to not mandate any specific cipher suite at all.

- 256 bit: There are definitely interest in using EDHOC with high-security cipher suites like 24 and 25. One reason is compliance with requirements such as the US CNSA. As TLS, DTLS, QUIC do not mandate high security cipher suites, it would maybe be a bit strange if EDHOC which has a strong focus on very constrained environments did so. I don't think it make sense to force e.g., 6TiSCH devices to implement cipher suite 24 or 25. AES-128 will provide excellent security for most deployments for the foreseeable future. We should also not force deployments using 24 or 25 to support, 0,1,2, or 3.

Cheers,
John

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 19 Dec 2021 02:25:10 +0000

John,

You made a great point that I missed. Thank you!

Indeed, I wouldn’t want suites 0,1,2,3 enabled in my apps, so the MTI consideration is moot.

My apologies for taking everybody’s time.

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

From: Lake <[email-masked]> on behalf of John Mattsson <john.mattsson=[email-masked]>
Date: Saturday, December 18, 2021 at 07:24
To: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

Hi,

My two cents:

  -  1. Transport protocol

  - 10. Cipher suite.

Cheers,
John

---

From: <[email-masked]>
Date: Mon, 20 Dec 2021 07:59:32 +0000

I think the MTI and interoperability discussion is a key topic:
The thought of a minimal set allowing my deployment to interwork with an arbitrary one is very appealing.

However, given the variation in pre-conditions and priorities in different environments together with the options listed by John,
I must say it seems like (a compact) “one size” will not fit all and a larger scope of MTI will be a burden in constrained deployments:
I find it really hard to say which of the 1-10 that would be acceptable and make sense  - for all deployments - in terms of key management, security level, message sizes etc.

Best
Peter

From: Lake <[email-masked]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: den 19 december 2021 03:25
To: [email-masked]
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

John,

From: Lake <[email-masked]<mailto:[email-masked]>> on behalf of John Mattsson <john.mattsson=[email-masked]<mailto:john.mattsson=[email-masked]>>
Date: Saturday, December 18, 2021 at 07:24
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

Hi,

My two cents:

  -  1. Transport protocol

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Dec 2021 09:37:10 -0500

> an arbitrary one is very appealing.

Agreed.  We just need a diety to give us the one true encryption algorithm :-)

    > I find it really hard to say which of the 1-10 that would be acceptable
    > and make sense  - for all deployments - in terms of key management,
    > security level, message sizes etc.

What I see is that constrained libraries will have compile-time options, and that
non-constrained systems will attempt to support them all with runtime policies.
The biggest challenge in target systems will be having a CBOR/COSE library
that is both minimal enough, but also capable enough to support EDHOC.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 20 Dec 2021 17:45:07 +0000

On 12/20/21, 09:38, "Lake on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:
>  Agreed.  We just need a deity to give us the one true encryption algorithm :-)

For now, that algorithm is AES. :-) ;-)
Have it, and enjoy! :D

>  that is both minimal enough, but also capable enough to support EDHOC.

In one word - yes.