Last Call Review of draft-ietf-lake-edhoc-18
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