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

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

Dear John,

Thank you for your reply!

>> 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?
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 <[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
>
>