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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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

 

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 <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Saturday, December 18, 2021 at 07:24
To: "[e-mail]" <[e-mail]>
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

 

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