Re: [Cfrg] Review of draft-selander-ace-cose-ecdhe-12

[John Mattsson <[e-mail]>]

Thanks for yet another great review Stanislav!

I tried to address all your and Russ' comments in the GitHub version of the draft:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-selander-ace-cose-ecdhe.txt&url2=https://EricssonResearch.github.io/EDHOC/draft-selander-ace-cose-ecdhe.txt

- I made an issue of "Is the added complexity of "C_U : bstr / nil" worth the bytes saved"

- I also included your comments regarding algorithms and cipher suites in the existing issue "Mandatory and optional cipher suites and algorithms.

- Based on the comments from Russ (and similar offline from Karl Norrman) I renamed aad_2, aad_3 and exchange_hash to transcript hashes (TH_2, TH_3, TH_4) and added an introduction of them to the beginning of the document where it is mentioned what EDHOC adds on top of SIGMA. This naming is hopefully better and by talking about them early, they do not come as a surprise in the key derivation section.

>While the choice of the ciphersuites seems to be acceptable, it will
>inevitably be a discussion point (e.g., should we include a GCM suite or
>even a suite with an internal re-keying mechanism as a countermeasure
>against side-channel attacks? should we include a suite with P224 as a
>lightweight alternative? etc.).

Interesting suggestions. GCM is standardized by COSE and could be added at any point. Currently many constrained IoT systems have a preference for AES-CCM with 8 byte tags and some older hardware are hard coded for AES-CCM with L (called q by NIST) = 2 as that is what is used in IEEE 802.15.4. An algorithm with internal re-keying and P-224 would first have to be standardized by COSE. P-224 for EDCH and ECDSA would save a total of 24 bytes when asymmetric authentication is used and 8 bytes when symmetric authentication is used.

Somewhat related to this discussion, there are existing "issues" on GitHub discussing if it should also be possible to send cipher suites as an array of COSE algorithms without first having to register an EDHOC cipher suite, and if different AEADs could be used for EDHOC and the following application layer protocol. One could for example use AES-CCM with 128 bit tags in EDHOC and 64 bit tags in OSCORE.

> "where salt = 0x in the asymmetric case"

This is supposed to be the empty byte string. I changed this to "0x (the empty byte string)" to make it clear.

>"KID does not need to uniquely identify the PSK ..." - is this possibility
>really needed for applications of the protocol? Absence of unique
>identification of the PSK possibly leaves some potential attack surface -
>the reviewer thinks that marking this as "NOT RECOMMENDED" will be better.

I changed the text to say "It is RECOMMENDED that it uniquely identify the PSK".
The feature we would like to have is the ability to use short identifiers. In the examples
in Appendix B we use 4 byte identifiers, if assignment of the identifiers are not coordinated
there could be collisions. Do you see any problems beyond that having n symmetrical keys
with the same identifier lowers the forgery complexity of a MAC with log2(n) bits?

Cheers,
John

From: "Stanislav V. Smyshlyaev" <[e-mail]>
Date: Friday, 1 March 2019 at 21:30
To: CFRG <[e-mail]>, John Mattsson <[e-mail]>
Subject: Review of draft-selander-ace-cose-ecdhe-12

Dear colleagues,

The Crypto Review Panel members were asked to provide two reviews of this document - sending the second one.

Document: draft-selander-ace-cose-ecdhe-12
Reviewer: Stanislav Smyshlyaev
Review Date: 2019-03-01
Summary: Minor revision needed

EDHOC is an authenticated key exchange protocol intended for usage in constrained scenarios, based on deeply analyzed SIGMA-I protocol. A formal verification of (a slightly different version of) the EDHOC protocol was conducted in [1] using automatic protocol verifier ProVerif.

The formal verification paper [1] contains not only the technique and the results of the verification, but also a number of recommendations (for the version -08 of the draft). Those recommendations mostly include concerns about unprotected (or, better to say, not fully protected) data that is sent in the protocol messages during mutual authentication and key exchange.

According to the formal analysis conducted in [1], EDHOC provides the declared security properties. In general, additional security analysis of a protocol should be conducted (not only with automatic tools, but also with security proofs by reduction, with a survey of countermeasures against typical attacks on AKE protocols, etc.), but the reviewer believes that for EDHOC, being a particular case of SIGMA-I (with additional messages and with AEAD instead of MAC-then-Encrypt), it is not critical.

While the choice of the ciphersuites seems to be acceptable, it will inevitably be a discussion point (e.g., should we include a GCM suite or even a suite with an internal re-keying mechanism as a countermeasure against side-channel attacks? should we include a suite with P224 as a lightweight alternative? etc.).

The EDHOC protocol looks well-designed. Particularly, the reviewer would like to mention such solutions as CRED_x under signature, which is good to prevent DSKS-type attacks; a downgrade protection based on sending both a list of supported suites and a selected one with aad2 and aad3 messages being hashes from all previous messages (binding the communications together); KCI-attacks are inapplicable due to SIGMA-like ephemeral keys usage.

The concerns of [1] (namely, section 2.3 of [1]) has been addressed. Application data in the second message (UAD_2) is no longer encrypted, which seems to be better for overall security. Indeed, while it weakens the security properties achieved for UAD_2, they become much clearer: the problem is that the encryption of UAD_2 in -08 took place with no guarantees of confidentiality before successfully finishing the protocol - and this issue is a very subtle one, potentially leading to incorrect security assumptions from the application side and vulnerabilities of the applications relying on confidentiality of that data. Therefore, -12 completely addresses the concern outlined by [1] for -08.

Section 9.4 of the draft contains a brief outline of security considerations regarding UAD_1, UAD_2 and PAD_3, which reflects considerations given in [1]. It is important that in 4.4.3 there are explicit instructions to pass PAD_3 to an application only if (and after) verification step succeeds.

The draft looks complete except for several minor concerns listed below.

Minor concerns:
A2.3
"where salt = 0x in the asymmetric case" - a specific value of salt here seems to be forgotten

In 4.4.3 there are explicit instructions to pass PAD_3 to an application only after verification step succeeds – but it seems also reasonable to add corresponding recommendations (to finish the verification step before sending PAD_3 to the application) to 9.6 ("Implementation Considerations").

This doesn't seem to be crucial for the security, but I believe that it would be helpful to provide a comment in Section 3.3 about the reasons why PSK is used as a 'salt', not as a "secret" in HKDF.

"KID does not need to uniquely identify the PSK ..." - is this possibility really needed for applications of the protocol? Absence of unique identification of the PSK possibly leaves some potential attack surface - the reviewer thinks that marking this as "NOT RECOMMENDED" will be better.

Nits:
1.1:
"Constrained IoT systems often deals" -> "Constrained IoT systems often deal"
"Requirements on network formation time can in constrained environments" -> "Requirements on network formation time in constrained environments can "
3:
"All EDHOC messages consists" -> "All EDHOC messages consist"
3.1:
"EDHOC cipher suites consists" -> "EDHOC cipher suites consist"
3.3:
"in the in the selected" -> "in the selected"
4.1:
"ID_CRED_U and ID_CRED_V contains" -> "ID_CRED_U and ID_CRED_V contain"
"Party U and Party V MAY use different type of credentials" -> "Party U and Party V MAY use different types of credentials"
4.3.2:
"Note that protected and signature" -> "Note that 'protected' and 'signature'"
4.4.2:
"Note that protected and signature" -> "Note that 'protected' and 'signature'"


[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf