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

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

Hi Marc and Felix,

Thanks very much for the early feedback from your analysis! We hope to get back with a response next week.

Just a brief note regarding your main point 2 below: Since the main use of EDHOC is to establish keys for an application protocol there is currently no "final" session key defined. For several reasons, including your comments, we consider to follow the proposal in #269<https://github.com/lake-wg/edhoc/issues/269>.

Thanks,
Göran



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

 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.

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


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

 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?

 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?

 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?

 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.

 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?


We hope these initial comments are helpful and look forward to some clarifications of the questions we have.

Kind regards,
Felix Günther and Marc Ilunga


[1] https://github.com/tlswg/tls13-spec/pull/875<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-52dd5274465d8d15&q=1&e=b37505b6-16f4-440f-808b-f9927ad4ffcf&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fpull%2F875>