Last Call Review of draft-ietf-lake-edhoc-20
review-ietf-lake-edhoc-20-secdir-lc-perlman-2023-08-08-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 | 2023-08-04 | |
Requested | 2023-07-07 | |
Authors | Göran Selander , John Preuß Mattsson , Francesca Palombini | |
I-D last updated | 2023-08-08 | |
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/X4rS8_i_GaoV6i1xxDEDFImCOfc | |
Reviewed revision | 20 (document currently at 23) | |
Result | Ready | |
Completed | 2023-08-04 |
review-ietf-lake-edhoc-20-secdir-lc-perlman-2023-08-08-00
Review result: Ready 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 use in "constrained" environments (think IoT) that replace other IETF protocols that would 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 differences do not appear to affect security and favor simplicity over optimization in the case of repeated connections between the same endpoints. 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. The issues raised in my last review (of -18) have been adequately addressed (either with changes or explanations on the list). Radia