[Dtls-iot] draft-hartke-dice-profile-03 comments

[Zach Shelby <[e-mail]>]

Here is my initial review on the draft-hartke-dice-profile-03. Overall, I think this is an excellent start. I can already see IoT developers cracking down cold beer and enjoying this document, it is going to save people a lot of time and misunderstanding about DTLS in this space.

General comments

- The text often refers to keying material being installed or updated via firmware update. Although that could be the case for some limited systems (or just for the purpose of bootstrapping), we are seeing key management and more generally device management for IoT device security configuration. We don't want to give implementers the impression that they should be hard-coding security configurations in firmware, as that get unmanageable quickly. We should probably talk about "software update or security management mechanisms". For example when this profile would be used for Lightweight M2M for example, such security management is provided by that standard itself over CoAP.

- The draft talks about only specifying Client functionality, but then in reality there are quite a few implementation requirements on Servers too…

Section 1

"is likely to be useful for IoT scenarios as well" - Is this maybe a little too unsure. As DTLS is required already by several standards for IoT, it is safe to assume DTLS will be widely used for IoT. This document is meant to make it a lot easier to use, implement and interoperate.

Section 2

Some possible text to help clarify Client and Server terminology here:

"Note that "Client" and "Server" in this document refer to TLS roles, where the Client initiates the TLS handshake. This does not restrict the interaction pattern of the protocols carried inside TLS as the record layer allows bi-directional communication. In the case of CoAP the "Client" can act as a CoAP Server or Client."

Section 4

If the RFC4279 PSK identity and key length requirements are not applicable to this profile, we probably need to define what are?

Section 5

Regarding the question, the must implement cipher required by CoAP for DTLS was chosen to align with device hardware (802.15.4 SoCs typically have AES-CCM hardware engines) and other standards like SE2.0 that requires that cipher. It is probably out of scope for us to start changing that in DICE. Of course that is only the must implement cipher suite, a DTLS implementation can support others.

Section 6

The EUI-64 is not a required by CoAP for use as the Authority Name, but is used as an example of a stable endpoint identifier. So I would say:

"For client certificates the identifier used in the SubjectAltName or in the CN is a stable endpoint identifier such as an EUI-64 [EUI64], as described in Section 9.1.3.3 of [I-D.ietf-core-coap]."

Section 10

Regarding PFS and the chosen cipher suite, we should again probably leave that to CoRE as implementers of course can support other cipher suites. We could e.g. require that Servers support the sheffer-tls-bcp recommended ciphers for interoperability with a Client that choses to use them?


Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: [phone]
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/


-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782