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

["Stanislav V. Smyshlyaev" <[e-mail]>]

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