[Atlas] Review/discussion of ATLS related drafts

["Owen Friel (ofriel)" <[e-mail]>]

Folks,

We never did get sufficiently organised to discuss this further in Montreal. Hopefully, this email will kick start some discussions that we can continue in Bangkok.

There have been quite a few different drafts, some current, some expired, mentioned on the mailers over the past year, and I've attempted to summarise the most relevant ones, and how they relate to ATLS, here:


#

draft

Expires

Main Authors

Summary

ATLS Relevance

1

draft-selander-ace-cose-ecdhe

01-19

Ericsson

Ephemeral Diffie-Hellman Over COSE (EDHOC)
Defines an ECDH SIGMA based key exchange algorithm using COSE and COBR objects. It defines explicit parameter inputs to COSE and explicit signature, hash and encryption algorithms. Encryption is fixed as AES-CCM-64-64-128. Authentication is based on OOB provided PSK, RPK or Cert.

At a high level, trying to solve a similar problem: a key exchange algorithm that can be transported over any layer

2

draft-hartke-core-e2e-security-reqs

01-18

Ericsson,
Uni. Bremen

Requirements for CoAP End-To-End Security
Lists requirements for CoAP e2e security

Explicitly lists e2e application layer security as a key requirement, which is a key use case ATLS is trying to address.

3

draft-ietf-lwig-security-protocol-comparison
(replaces
draft-mattsson-core-security-overhead)

01-19

Ericsson

Comparison of CoAP Security Protocols
Gives a header overhead byte count comparison of various encryption protocols (D/TLS 1.2/3, OSCORE).

Relevant as ATLS uses D/TLS protocol format. It would be worth noting that the overall data stream overhead of D/TLS headers is not as important if D/TLS is only used for key negotiation and key export and then OSCORE is used for encrypted data transport.

4

draft-ietf-core-object-security

12-18

Ericsson

Object Security for Constrained RESTful Environments (OSCORE)
Uses COSE for COBR to protect CoAP messages e2e. It uses pre-shared keys that have been established OOB.

It does not cover key agreement, so ATLS for key agreement could be complementary to this.

5

draft-hartke-dice-practical-issues
(replaces draft-hartke-core-codtls)

10-14

Uni. Bremen

Practical Issues with DTLS in Constrained Environments
Outlines issues with fragmentation, packets loss, retransmissions etc. with DTLS in lossy constrained environments and gives a strawman for DTLS header compression.

While the highlighted issues are relevant for ATLS handshake packet transport over lossy networks, most of the issues have been addressed in other later drafts (e.g. DTLS1.3, RFC7925).

6

draft-schmertmann-dice-codtls

02-15

Uni. Bremen

CoDTLS: DTLS handshakes over CoAP
Defines how DTLS packets can be encoded into CoAP packets.

This is very relevant as there is an empty placeholder section in the ATLS draft on the encoding of D/TLS records over CoAP.

7

draft-garcia-core-app-layer-sec-with-dtls-record

06-17

Uni. Murcia

Application Layer Security for CoAP using the (D)TLS Record Layer
Defines how CoAP messages and headers can be partially encrypted using keys that have been derived out of band. The bare minimum CoAP header info is left unencrypted to enable proxies to route packets, but not decrypt content.
It also touches on breaking apart handshake from encrypted data packet transport.


Similar, to OSCORE, it does not cover key agreement, so ATLS could be complementary to this. But the OSCORE draft, not this draft,  seems to be the preferred path forward.

8

draft-bhattacharyya-dice-less-on-coap

09-18

TATA

Lightweight Establishment of Secure Session (LESS) on CoAP
Assuming that a PSK is exchanged OOB, it defines a new key agreement algorithm using some novel crypto that would need a thorough security review.
It also alludes to breaking apart handshake from encrypted data packet transport

At a high level, trying to solve a similar problem to both EDHOC and ATLS: it defines a key exchange algorithm.

9

draft-kuehlewind-taps-crypto-sep

01-19

ETH Zurich,
Apple

Separating Crypto Negotiation and Communication
Wants to explicitly break apart handshake packets from encrypted data packets so that handshake can happen in advance of packet transport. Acknowledges that there is no real benefit if encrypted data transport happens immediately after handshake.

We do mention using ATLS for handshake with key exporting, and encrypted data exchange happening out-of-scope of ATLS draft. Future TLS stack API optimisations could possibly be leveraged by ATLS to facilitate handshake vs. payload transport.


It appears as if the concepts from the ATLS draft combined with the CoDTLS work could be considered as viable alternatives to the EDHOC or LESS  proposals. There are advantages and disadvantages to both approaches which are worth discussing here. The ATLS approach has the advantage of not requiring definition of any new key negotiation protocol, we can use existing stacks as is, and piggy back on top of D/TLS1.3 protocol. Similar to EDHOC Appendix D, ATLS w/CoDTLS could be used as the key negotiation mechanism for OSCORE.

It would be great if we could have some discussions on the mailer prior to Bangkok, and see if there is any interest in having a side-meeting/lunch in Bangkok to discuss next steps and see if we can reach any consensus.

Cheers,
Owen