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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 1 Mar 2019 23:29:41 +0300

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 1 Mar 2019 16:07:51 -0500

> On Mar 1, 2019, at 3:29 PM, Stanislav V. Smyshlyaev <[email-masked]> wrote:
> 
> Minor concerns:
> 
> 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.

I did not comment on it in my review, but I did not this when I read the document.  I actually thought it was kind of clever.

That said, RFC 5869 defines the salt as:

      salt     optional salt value (a non-secret random value);
               if not provided, it is set to a string of HashLen zeros.

So, while I have no concerns about the security of the construction, I do think the Security Considerations need to say that the PSK needs to be kept secret even though it is being input into the KDF as salt.

Russ

---

From: John Mattsson <[email-masked]>
Date: Sun, 3 Mar 2019 11:16:20 +0000

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.

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

>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" <[email-masked]>
Date: Friday, 1 March 2019 at 21:30
To: CFRG <[email-masked]>, John Mattsson <[email-masked]>
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.

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.

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

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

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 4 Mar 2019 08:58:21 +0300

Dear John,

Thank you for your reply!

>> with the same identifier lowers the forgery complexity of a MAC with
log2(n) bits?
Beyond that (and similar trivial impersonation attacks: A has PSK1 for
mutual authentication with B and PSK2 for mutual authentication with C,
identifier(PSK1) = identifier(PSK2) - C can try to impersonate B in front
of A), most of all I don't like that this option lies beyond the security
analysis - and it's always dangerous to have protocol options (ones that
are connected with key management, at least) that have not been taken into
account during security assessment (tricky interleaving attacks happen to
exploit such options in protocols).

>> I changed the text to say "It is RECOMMENDED that it uniquely identify
the PSK".
Yes, I'd agree with that, John!

Many thanks again for your important work and for your reply!

Kind regards,
Stanislav

вс, 3 мар. 2019 г. в 14:16, John Mattsson <[email-masked]>:

> - 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.
>
>
>
> 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.
>
>
>
> *From: *"Stanislav V. Smyshlyaev" <[email-masked]>
> *Date: *Friday, 1 March 2019 at 21:30
> *To: *CFRG <[email-masked]>, John Mattsson <[email-masked]>
> *Subject: *Review of draft-selander-ace-cose-ecdhe-12
>
>
>
> Dear colleagues,
>
>
>
> "Requirements on network formation time can in constrained environments"
> -> "Requirements on network formation time in constrained environments can "
>
> 3:
>
> "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:
>