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

[Hannes Tschofenig <[e-mail]>]

Hi all,

on Friday I submitted an updated version of draft-hartke-dice-profile,
the DTLS 1.2 profile for IoT.

Version 02 of the document only contained an table of contents and the
updated version now includes content within the sections. Given the
large number of changes to the document I believe it would be beneficial
to get some agenda time at the upcoming meeting. I would like to go
through the recommendations in the document to solicit feedback from the
group.

The following questions appear interesting to me:

1) Is the communication model described in Section 2 a good starting
point? Are there other communication models the group would like to see
discussed? While the focus on unicast communication is likely not to be
controversial (since there is a separate document in the charter of the
group focused on multicast security with DTLS) there are still many
other communication models to focus on even for unicast.

2) Are the recommendations regarding the PSK ciphersuite sound?

3) Are the recommendations for the use of raw public keys appropriate?

4) Are the recommendations for certificate use useful?

5) Section 7 discusses error handling and gives recommendations
regarding various error codes. Is this level of detail useful for you?

6) Currently Section 8 recommends session resumption to be implemented
and used. The downside of it is the additional RAM and code
requirements. On the plus side the improved crypto performance, energy
consumption, and lower bandwidth requirement.

7) The document recommends not to use compression at the TLS layer. Is
this OK?

8) Section 10 briefly talks about PFS and notes that the PSK ciphersuite
does not offer PFS. The downside of PFS is the cost of generating and
using Diffie-Hellman crypto. The plus is that is offers additional
security features, namely forward secrecy.

9) Section 11 points to the keep-alive extension and ask the question
whether it should be used or not. Do people have experience with it?

10) Regarding downgrading attacks this profile argues that
I-D.bmoeller-tls-downgrade-scsv does not need to be used. To mitigate
the TLS renegotiation attack [RFC5746] the recommendation is made to not
use renegotiation at all.

11) Privacy: I have added a discussion about privacy to the document.
Some of you might have other suggestions on how to structure the text or
other concerns.

Smaller issues are:

a) How important is the alignment with recommendations given in
I-D.sheffer-tls-bcp? (raised in Section 5)

b) Should we provide some indication about the level of the certificate
hierarchy? (raised in Section 6)

c) How much should we focus on CoAP vs. non-CoAP based protocols for use
with this DTLS profile?

There is also text missing from the draft, namely a discussion
about what extension from RFC 6066 to re-use. My current thinking is
that we should support the following two extensions:

* Client Certificate URLs: With the TLS cached info extension the client
can cache server certificate chains but in order to avoid sending the
client certificate + chain the certificate URL is ideally suited leading
to a significant reduction in message size.

* Trusted CA Indication: This allows the client to indicate what trust
anchor it has and therefore allows the server to make more informed
decisions about what to return to the client. Since the client will only
have a few trust anchors the size of data that is sent to the server is
small.

I think that the Truncated MAC extension is an extension useful to
reduce the size of the MAC included in the Record Layer. However, if we
use more modern ciphersuites based on the AEAD design then they already
offer shorter authentication tags anyway. Hence, I believe we don't need
this extension.

For the Server Name Indication and the Maximum Fragment Length
Negotiation extensions I am not sure.

Comments are welcome.

Ciao
Hannes