Change:
and cipher suite negotiation.  Authentication can be based on raw public keys (RPK) or public key certificates and requires the application to provide input on how to verify that endpoints are <del> trusted.  This specification emphasizes the possibility of referencing rather than to transport credentials in order to reduce message overhead, but the latter is also supported.  EDHOC does not currently support pre-shared key (PSK) authentication as authentication with static Diffie-Hellman public keys by reference produces equally small message sizes but with much simpler key distribution and identity protection. EDHOC makes use of known protocol constructions, such as SIGMA SIGMA and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR encoded X.509 (C509) certificates, see auth-cred).  COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT. </del> <ins> trusted.  This specification supports the referencing of credentials in order to reduce message overhead, but credentials may alternatively be embedded in the messages.  EDHOC does not currently support pre-shared key (PSK) authentication as authentication with static Diffie-Hellman public keys by reference produces equally small message sizes but with much simpler key distribution and identity protection. EDHOC makes use of known protocol constructions, such as SIGMA SIGMA, the Noise XX pattern Noise, and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR encoded X.509 (C509) certificates, see auth-cred). COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT. </ins> EDHOC is designed for highly constrained settings making it especially suitable for low-power networks RFC8376 such as Cellular

Discussion:
Merging this as no new comments appeared.
From: Radia Perlman Date: Tuesday, 24 January 2023 at 03:49 To: EMAIL , The IESG , EMAIL Subject: Secdir review of draft-ietf-lake-edhoc-18 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. There are a family of "lightweight" protocols designed for us in "constrained" environments (think IoT) that replace other IETF protocols that would be otherwise be used. The constraints may include lack of CPU power, lack of bandwidth, lack of non-volatile memory, and running over a non-IP network. EDHOC (Ephemeral Diffie-Hellman over COSE) specifies a protocol for establishing session keys for use with OSCORE that specifies how to cryptographically protect a session. So you can think of EDHOC as corresponding to IKE while OSCORE corresponds to ESP, or you can think of the pair EDHOC/OSCORE as corresponding to TLS. As you would expect, the protocol is functionally quite similar to both TLS and IKE, and the interesting security discussions would be around the justifications for the differences. The name EDHOC is misleading, since EDHOC supports four authentication variants, only one of which is Ephemeral Diffie-Hellman. The other three are where one of both endpoints use a static Diffie-Hellman key. TLS 1.3 decided to abandon all such variants because they do not provide forward secrecy, but I suppose it reasonable to revisit that decision in the context of a constrained environment. But I can think of no justification for the misleading name. The working group name (Lightweight Authenticated Key Exchange - LAKE) would be a more accurately descriptive name. The authors may be confused about the definition of forward secrecy, since in Security Considerations they say this protocol provides forward secrecy and in Appendix J they refer to a key refresh technique that has some nice security properties but does not provide what is generally regarded as forward secrecy. Other differences: They simplify the protocol compared to TLS by not including the variations allowing restart of a security context based on cached information.

While this makes the code to implement the protocol simpler, it hurts performance. The negotiation of cryptographic algorithms is based on suites (as early versions of TLS did) rather than a more ala carte approach that TLS has evolved towards. Further, while TLS has a system of initiator proposes and responder chooses cryptographic algorithms, in EDHOC's system the responder is constrained to choose the most preferred of the initiator's suites that it supports. Further, the initiator must guess the suite the responder will choose and the protocol may be very "chatty" the first time the protocol is run (or every time if the initiator does not cache the preferred suite of the responder). There would be an extra pair of messages for each suite the initiator prefers over the first one the responder accepts. Whether authentication is going to be based on Ephemeral or Static Diffie-Hellman keys is not negotiated. The initiator is expected to know (or the protocol gets more chatty). Finally, rather than negotiating a symmetric encryption algorithm for use within EDHOC itself, EDHOC generates an extended PRF output which it XORs into messages to encrypt them. In practice, this strikes me as a clever hack to greatly simpify the specification while not substantially hurting performance. But others may disagree. There was a reference to an analysis of the security of the protocol (which is based on SIGMA). I didn't read it, but the design of the protocol looks sound to me. Nits: From Section 1.1: "This specification emphasizes the possibility to reference rather than to transport credentials in order to reduce message overhead, but the latter is also supported." -> "This specification supports the referencing of credentials in order to reduce message overhead, but credentials may alternatively be embedded." In Section 3.9: "incompliance" -> "non-compliance" Radia
Addressed in
Comment from Loïc: I am wondering if the computational independence of the intermediary secret keys has been discussed. I looked among the different issues on the Github repository but did not find any reference to that point. Indeed in his on SIGMA, Krawczyk stresses that the (intermediary) authentication keys, encryption keys and the session key must be computationally independent: (§5.1, p.

17) “It is essential for the protocol security that the keys Km [MAC key] and Ks [session key] be “computationally independent” (namely no information on Ks can be learned from Km and vice-versa).” (§5.2, p. 19) “Ke [intermediary encryption key] must be computationally independent from the authentication key Km and the session key Ks” It happens that this is not always true in EDHOC depending on the authentication mode. The most demonstrative example is with the Sig-Sig mode. PRK2e is used to compute the authentication tag MAC2. If this key is disclosed, all the intermediary secret parameters (tags, keys, IVs) and the session key PRKout can be computed. Using a static DH key to authenticate adds more independence. For example, with the Sig-Stat mode, the disclosure of PRK4e3m = PRK3e2m used to compute MAC3 does not allow computing the session key PRKout unless TH4 = H(TH3, PLAINTEXT3, CREDI) is revealed (and PLAINTEXT3, IDCREDI are encrypted, as well as PLAINTEXT2, IDCREDR where TH3 = H(TH2, PLAINTEXT3, CREDR)). In addition, this shows that the computational independence does not rely only on the function used to compute the intermediary keys but also on the encryption schemes used to protect PLAINTEXT2, IDCREDR and PLAINTEXT3, IDCRED_I. So I wanted to know if this has already been discussed (and possibly discarded since one way to leverage this lack of independence is to get one these intermediary keys, which may not be trivial in practice).
This issue was discussed and actually concluded in an email exchange before Christmas but we forgot to update the issue. The conditions on SIGMA listed in this issue does not apply to EDHOC. This is one example of a difference with SIGMA. The security analysis papers of EDHOC listed in Section 8.1 show that the relevant security properties still apply. The clarifications of security properties in PR cover also this issue.
Closing this, as is merged.