Skip to main content

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