Last Call Review of draft-ietf-lake-edhoc-18
review-ietf-lake-edhoc-18-secdir-lc-perlman-2023-01-26-00
Request | Review of | draft-ietf-lake-edhoc |
---|---|---|
Requested revision | No specific revision (document currently at 23) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-12-31 | |
Requested | 2022-12-05 | |
Requested by | Stephen Farrell | |
Authors | Göran Selander , John Preuß Mattsson , Francesca Palombini | |
I-D last updated | 2023-01-26 | |
Completed reviews |
Secdir Last Call review of -20
by Radia Perlman
(diff)
Secdir Last Call review of -18 by Radia Perlman (diff) Genart Last Call review of -18 by Christer Holmberg (diff) Intdir Last Call review of -18 by Donald E. Eastlake 3rd (diff) Tsvart Last Call review of -18 by Michael Scharf (diff) |
|
Assignment | Reviewer | Radia Perlman |
State | Completed | |
Request | Last Call review on draft-ietf-lake-edhoc by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/UrdUxov6snyvLEiiOQNJRX1qYk8 | |
Reviewed revision | 18 (document currently at 23) | |
Result | Has issues | |
Completed | 2023-01-24 |
review-ietf-lake-edhoc-18-secdir-lc-perlman-2023-01-26-00
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