Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

[Robert Cragie <[e-mail]>]

Hi Hannes,

Further to your example, as mentioned earlier, Thread Commissioning [1] also secures CoAP end-to-end using DTLS through a number of middleboxes. See figure 11 in [1], where the JOIN_FIN req.rsp messages are CoAP messages in the joining session, secured all the way from the untrusted joining device over an insecure first hop to the Commissioner (which could be cloud-based). Note also that the Commissioner is typically a smart phone, for which there are readily-available TLS implementations thus making development of a commissioning app for Thread [2] relatively straightforward. The OpenThread stack [3] for developing Thread-based devices uses a single instance of the mbedTLS library for Thread Commissioning, where that library is also available for application layer security in the device. Thread does use a non-standard cipher suite based on EC-JPAKE [4] but it was relatively straightforward to add this cipher suite to mbedTLS using the existing framework and building blocks already in place.

Note all of this predates ATLS but the principles are exactly the same. ATLS caters for a wider range of use cases.

Robert

[1] https://www.threadgroup.org/Portals/0/documents/support/CommissioningWhitePaper_658_2.pdf
[2] https://play.google.com/store/apps/details?id=org.threadgroup.commissioner
[3] https://openthread.io/
[4] https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01

From: Lake <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: 26 June 2020 09:57
To: Blomqvist, Peter <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Hi Peter,


  *   We can provide some input on use-cases and current issues we face with (D)TLS:.

This would be highly appreciated and timely given that there is this TLS / DTLS profile work ongoing in the UTA working group.


  *   Also please clarify “cTLS” – is that for key export or full replacement of OSCORE?

cTLS refers to the approach of compressing TLS. Here is the draft: https://tools.ietf.org/html/draft-ietf-tls-ctls-00
It has applicability beyond IoT, which is why the TLS working group adopted it.

OSCORE is conceptually similar to the TLS/DTLS record layer. The most natural way of using DTLS/TLS or cTLS would be to use it with its native record layer. Then, you obviously don’t need OSCORE.
For example, in this email thread Hari from u-blox referenced the work he did at u-blox as part of a government funded research project to protect CoAP from an IoT device over BLE to a gateway and then to the cloud. He is using OSCORE in his setup. We are using DTLS 1.2 over BLE (and then over WebSocket) in a commercial deployment where we protect CoAP entirely (end-to-end*) without using OSCORE.  We call this ATLS (application layer TLS) because TLS (or DTLS) is carried (at least in some segments of the communication path at the application layer). The ATLS spec (see https://tools.ietf.org/html/draft-friel-tls-atls-04) also adds a description on how to derive keying material for OSCORE.

Ciao
Hannes

(*): The term “end-to-end” is often over-sold because in most cases CoAP communication isn’t truly end-to-end. So, in practice one has to be careful to figure out what the “end points” in the communication are.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.