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

[Hannes Tschofenig <[e-mail]>]

Hi Zach,

thanks for the review and sorry for the late response

Please find some responses inline:

On 03/03/2014 11:51 AM, Zach Shelby wrote:
> 
> 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.

It is probably a bit outside the space for this document to talk about
how exactly the credentials get to the device (since it has nothing to
do with DTLS itself).

It might be better to document the assumptions instead.

For example, with pre-shared secret TLS usage we assume that an
identifier and a shared secret was pre-provisioned to the TLS client.

I will make this change the next version of the document.

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

You are certainly right. The functionality the client uses has to be
supported by the server since otherwise nothing works.

However, what we tried to do is to balance the requirements in such a
way that the TLS server has to deal with complexity and not the client
(since the client is resource constrained in the current write-up).

> 
> 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.
> 
OK. Will fix it.

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

Makes sense. This reflects the issues.

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

I guess we cannot dictate how long they will be; we just need to point
out that implementations do not require allocating a minimum length.

[I should probably add that there might be cases where IoT devices have
a user interface and in those cases the requirements of RFC 4279 apply.]

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

What to say about ciphersuites is of course a bit tricky. The desired
properties seem to change quite quickly.

I suspect that developers would like to receive some guidance regarding
cryptographic algorithms and what their implications are. But choosing a
specific algorithm might make it somewhat challenging to be meet the
need of everyone.

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

The problem is of course the added flexibility since the choice of the
identify changes the way the authorization check is done.

The CoAP protocol is somewhat open on that issue and even allows the
identifier to be put into either CN or the SubjectAltName rather than
mandating one specific way.

In documents submitted to the ACE group I noticed that the examples
showing certificates had wrong identifiers in there that, particularly
in the context of server authentication, make uniqueness and the ability
to perform authorization checks difficult.

So, I think some guidance is useful but I will have to think about the
story a bit more.

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

The problem is that it is rather unlikely that constrained devices will
implement a range of different TLS ciphersuites since it directly
conflicts with the desire to keep the memory footprint small.

Overall, for the question is how strongly aligned with CoAP (and the
ciphersuite recommendations) we want to be.

Ciao
Hannes

> 
> 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
> 
> _______________________________________________ dtls-iot mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/dtls-iot
>