Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[John Mattsson <[e-mail]>]

Richard Barnes <[e-mail]>; wrote:

>This is the part that worries me.  It would be helpful to be very crisp
>about what assumptions are being changed here, and why it's OK for them to
>be changed.  Especially given that the Bruni et al. paper seems to have
>found flaws.

As explained in Stanislav's CFRG crypto review:

"The concerns of [1] (namely, section 2.3 of [1]) has been addressed."
https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8

As the concerns were about the ability of end users to understand the security properties of early application data, I think similar concerns could be made regarding (D)TLS 1.3. 

Regarding differences between EDHOC and TLS 1.3, EDHOC is closer to the deeply analyzed SIGMA-I protocol. Many of the additions TLS 1.3 do to SIGMA-I are as far as I know done to support additional features:

- Nonces enable TLS 1.3 to work with 0-RTT data, to support PSK mode without PFS, to work with static Diffie-Hellman keys in older versions of TLS, and to look like TLS to middleboxes and applications that expect TLS to look a certain way.

- A MAC in TLS flight #1 enables 0-RTT data.

- The split into handshake and record layer means that TLS flight #2 and #3 contain two MACs

Most of the additions EDHOC made to SIGMA-I are summarized in Stanislav's CFRG review:

"The EDHOC protocol looks well-designed. Particularly, the reviewer would
like to mention such solutions as CRED_x under signature, which is good to
prevent DSKS-type attacks; a downgrade protection based on sending both a
list of supported suites and a selected one with aad2 and aad3 messages
being hashes from all previous messages (binding the communications
together); KCI-attacks are inapplicable due to SIGMA-like ephemeral keys
usage."

(Similar additions are done in TLS 1.3 as well, but EDHOC aims for very simple solutions that keep the code and memory complexity as low as possible).

- Other differences are mainly in encoding and different design requirements, TLS supports a large number of additional extensions and options and it also has to interop with older versions. DTLS adds a lot of transport related things that EDHOC relies on CoAP for. TLS was designed with web servers as the main use case. EDHOC is not trying to replace TLS, I love TLS 1.3, and I advise Ericsson products and SDOs to use TLS as much as possible. But the TLS handshake was certainly not designed with constrained IoT as the main use case. We are trying to bring SIGMA-I level end-to-end protection to constrained IoT systems where TLS is impractical.

Cheers,
John