Re: [Lake] Computational EDHOC analysis - Some early comments and questions

[Göran Selander <[e-mail]>]

Hi Mark, Felix,

Again, thanks for very good comments and valuable feedback.

Apologies for slow response. Please find some first brief responses below, do let us know if there are further questions. We plan to get back next week with some PRs based on the security analysis feedback to date.


From: Lake <[e-mail]> on behalf of Ilunga Tshibumbu Mukendi Marc <[e-mail]>
Date: Thursday, 31 March 2022 at 15:18
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Lake] Computational EDHOC analysis - Some early comments and questions

Dear LAKE WG,

We are a team from ETH Zurich working on a computational analysis of EDHOC as a key exchange protocol. We are currently at an early stage of our work, but hope to have some preliminary analysis results in the next two months or so.
At this point, we're reaching out mainly to communicate a few early comments / questions based on our investigations so far. We hope this can clarify potential misunderstandings on our side before we dive deeper into our analysis.


Main points:

 1. Transcript Hashes:
 In Section 5.4.2, the draft states that TH_3 takes the ciphertext (of message 2) as input instead of the underlying plaintext; TH_4 works similarly. Is there a particular reason for including the ciphertext and not the plaintext (as done, e.g., in TLS 1.3)?
 (From an analysis perspective, hashing the ciphertext might introduce dependencies on the encryption method.)

[GS] The intent with the transcript hash is to include the content of all exchanged messages, which in the case of message 2 and 3 are encrypted. Please let us know if this has a substantial impact on the analysis or results.


 2. Session Key:
 It is unclear to us what is considered the "final" session key in EDHOC. PRK_4x3m seems to be the "final" key derived in the main document. As PRK_4x3m is however also used for deriving the encryption keys, MAC keys, OSCORE security context, exported material, etc., it is not an "independent and random-looking" key anymore by the time EDHOC completes, which would be the computational security guarantee one would ask for in a key exchange.

[GS] As mentioned, there is no "final" session key defined, since the default use of EDHOC is to establish keying material from which an application can derive session keys. This keying material is PRK_4x3m and TH_4, which perhaps could serve as "session key". However, based on other review comments we consider (with PR #276 as a starting point) to derive a key PRK_out from PRK_4x3m and TH_4 (using Expand) which perhaps is a better candidate "session key" for the analysis.


 3. Key Reuse in KDF:
 The key schedule uses PRK_2e, PRK_3e2m, and PRK-4x3m as inputs in both Extract and Expand (depending on the authentication mode). Such reuse of key material across is generally not secure. Concretely, in HMAC/KMAC-based derivation, one would need to carefully ensure domain separation between such calls. We point out that TLS 1.3, for specifically that reason, uses derived secrets (RFC 8446, Section 7.1: keys with label "derived") to separate Extract and Expand calls (cf. [1]).

[GS] Thanks, we indend to comply with this by deriving salts (using Expand) replacing the corresponding PRK. For PRK_4x3m, this will be replaced by the derivation of PRK_out (using Expand). A PR building on PR #276 will follow.

Secondary points:

 4. KDF Usage in KeyUpdate:
    1) The method takes a nonce to prevent "short cycles". What exactly is meant by that or the formal reasoning behind this?

[GS] We are revisiting the formal reasoning, but the rationale was similar as in stream cipher construction. Another reason for a nonce is to enable binding to the event that triggered the key update.

    2) Since Extract is used here as a PRF, the key (PRK_4x3m) should be the first input, and nonce the second.   (In that context, even a constant nonce would be fine; hence the question in 1).)
    3) To prevent key reuse across primitives, KeyUpdate should use Expand, not Extract. (see 3.)

[GS] Thanks, we will replace with Expand.

 5. Key Updates for OSCORE:
 As currently specified, it seems key updates will not influence the OSCORE security context (or other applications), as it seems such keys are not updated/re-derived. Is that intended?


[GS] Key update for OSCORE (KUDOS) makes use of EDHOC-KeyUpdate but is specified in a separate document:
https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-key-update


 6. Connection Identifiers:
 The draft states that CIDs have no cryptographic purpose (Section 3.3), but at the same time that they may be used to identify keys (Section 2), which sounds like a cryptographic purpose. What are we misunderstanding?

[GS] In EDHOC the connection identifiers are used for identifying the protocol state. If the correct protocol state is not identified, the message processing may fail, but we didn't consider this primarily a cryptographic concern. We may rephrase this as " no other purpose than to identify protocol state " or similar if that makes more sense?


 7. MAC Length:
 On page 30, MAC lengths seem to be depending on the authentication mode (besides the ciphersuite). What is the reason behind changing MAC length based on the mode?


[GS] This refers to the truncation of the HKDF MAC. For reasons of overhead it is desirable with certain cipher suites if the message on the wire has a truncated MAC.  The modes (methods) differ in the Signature_or_MAC field being either a signature or a MAC. For static DH Signature_or_MAC is the HKDF MAC, which can be truncated. In case of signature Signature_or_MAC is a signature, so the HKDF MAC isn't truncated.


 8. XOR Encryption for Message 2:
 Why is message 2 encrypted via a one-time pad instead of using the AEAD scheme? While an attacker can of course impersonate the server at this point, an AEAD scheme still protects against manipulations by a so-far passive person-in-the-middle.


[GS] Encryption is used as in SIGMA for protecting the identities. We use the same scheme also for the static DH methods. Using an AEAD would add a MAC which increases the overhead.

 9. Usage of EADs:
 The security guarantees for EADs are not explicit. They are considered unprotected; however, they are also passed to security applications. Moreover, the draft states, "the content in an EAD field may impact the security properties provided by EDHOC." What security guarantees can be affected by the EADs?

[GS] The description of EAD is updated in the Editor's copy [1], there is now also an appendix E containing more details and assumptions. Since an application defines the use of EAD, the resulting security guarantees are not in scope of EDHOC. However, one specific use of EDHOC may be worth analysing: The case that the application makes use of an ephemeral key in the EDHOC exchange for the purpose of establishing an ephemeral-static DH shared secret using a static public key different from the authentication key of the responder.


Sorry for brief responses.

Thanks
Göran


[1] https://lake-wg.github.io/edhoc/draft-ietf-lake-edhoc.html