Subject: Re: [Dtls-iot] draft-ietf-dice-profile-04.txt

From: Michael StJohns <[email-masked]>
Date: Mon, 01 Sep 2014 20:14:58 -0400

On 8/31/2014 11:33 AM, Hannes Tschofenig wrote:
> Hi all,
>
> I just submitted a new version of the DTLS profile draft.
>
> I added text about the following issues:
>
>   * recommendation regarding the depth of the certificate chain
>   * use of gmt_unix_time in the ClientHello/ServerHello (based on
> [I-D.mathewson-no-gmtunixtime])
>   * remark about [I-D.ietf-tls-encrypt-then-mac] not being applicable to
> this profiles
>   * section about TLS session hash
>   * removed a few unused references
>   * re-grouped the authentication credential types into one section.
>
>

Hi Hannes -

Some comments on the document.  I think that its *almost* ready, but 
that you have a few things that you did this last pass that made it 
worse.  And there are still a few things that I think need to be fixed.  
Sorry for not reading this earlier.

----   Down refs - you've expanded the list of ID's that are normative 
and that's going to be problematic in getting this through the process.  
I'd remove each and every one of them and the related text.  
Alternately, I'd reduce the set of items you're dealing with and put the 
document on hold pending them moving to last call. For the three ID's 
that are listed as normative I'd dispose of the related issues as follows:
    session hash:  Delete and defer.  The attack they address with this 
is related to authentication after renegotiation more than anything 
else.  Since this document removes renegotiation, it's probably not 
critical to include this.
    gmt time in the random:  Delete the reference.  Indicate that the 
1.2 mechanism will be used (e.g. time included).  In general, the 
concern he states is related to fingerprinting and kind of silly to 
worry about on a constrained device.
    cached info:  Delete and defer.  This is an efficiency item.  I'd 
instead note the caching concerns and indicate that additional 
extensions may be specified in an update to the profile to improve them.

     informative IDs:  reform the text to eliminate the references.    
Otherwise you're going to be waiting a long time to get this through.  
Maybe create a second document to cover things like the extended cipher 
suites for PFS and PSK but that can wait until the down refs resolve?

For substitute text:  [At the time of publication, TLS and DTLS were 
undergoing substantial discussions on a large set of extensions and on a 
set of changes specific to version 1.3.  Where applicable, completed 
discussions (in the form of RFCs) have been referenced and discussed.  
It is anticipated that there will be either another version of this 
document or a second document addressing any further points resolved 
after this document is published.]

---- Minimum crypto implementation requirements.  One of the realities 
of TLS1.2 and 1.1 is that the PRF must be based on a hash function (due 
to the hash use to create the verify_data in the Finished message).  It 
might be worthwhile to state that all IOT implementations will need a 
SHA256 implementation at a minimum, even PRK based ones.  (You could 
pick another SHA function or even a non-NIST hash function, but that 
would probably not address the requirements for a small profile.)  I'm 
trying to figure out how to get this changed for TLS1.3 and later, but 
its not going well.  I *really* want to be able to build an IOT device 
using only the AES "encrypt block" operation, but that will require 
changes to how TLS does its handshake.

---- Section 3 third para - this probably needs to be weasel worded 
rather than stuck at "preconfiguration"  -  e.g. preconfigured to grab 
its configuration from somewhere for updates and changes.  In other 
words, suggest that the set of servers will be small, but that the 
profile doesn't limit them to the ones given at birth.  Also - DNS vs 
addresses? Profile requires devices to support at least addresses, but 
does not limit them.

---- Section 5.1 vs section three third paragraph - if all the clients 
have are addresses, then how can you figure out the PSK hint based on 
DNS?  (Page 9, second para in the PDF version).   Last paragraph of 
section 5.1 mentions the cipher suite, but doesn't include explicitly in 
the profile as I think was the desire.  E.g. "A device compliant with 
this protocol MUST implement this ciphersuite" should probably go in 
there somewhere.

---- Section 5.2 - same issue with inclusion of the cipher suite into 
the profile.

---- Section 5.3 - ditto.  Also, the depth of certificates is 
recommended to be limited to 3 - but there is no text suggesting how 
non-compliance is handled or what the implications of the recommendation 
is.  There's also an issue that this isn't specific to the length of the 
client certificate chain sent or the server certificate chain 
received.      Instead:  "IOT devices MUST provide support for a server 
certificate chain of at least 3 not including the trust anchor and MAY 
reject connections from servers offering chains longer than 3.  IOT 
devices MAY have client certificate chains of any length.  Obviously, 
longer chains require more resources to process, transmit or receive."   
One useful reference in this section may be 802.1AR which discusses the 
difference between IDevID certificate and LDevID certificates (initial 
and locally significant certificates) and talks about certificate chain 
length for the two types of devices.

-- Nits:

unicast - not uni-cast (2nd para of section 3)

Title - the title is broader than the document.  This is a profile for 
DTLS for constrained IOT client devices, not for the IOT as a whole.    
Instead: "A DTLS1.2 Profile for Constrained IOT Clients".

Definitions:  What exactly is a "constrained" device?  When does this 
profile apply vs something else?  The one line reference to sensors in 
the abstract isn't sufficient.

Later, Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Sep 2014 17:57:47 +0200

Hi Mike,

thanks for your good review. Feedback inline:

On 09/02/2014 02:14 AM, Michael StJohns wrote:> On 8/31/2014 11:33 AM,
Hannes Tschofenig wrote:
> document on hold pending them moving to last call.

You are right that the list of normatively referenced drafts increased
from 1 to 3 with the most recent draft update.

For the three ID's
> critical to include this.

Actually, I read it differently and believe that the attack is also
applicable to the case where you run server-side only authentication at
the TLS layer and then run a weak client-side authentication at the
application layer. While it is not applicable for the document as
specified (as described in the body of the document) I could very well
imagine that developers will try to deal with device authentication in
that way (particularly if they want to interwork with existing
infrastructure that does not support some of the ciphersuites or features).

>    gmt time in the random:  Delete the reference.  Indicate that the 1.2
> mechanism will be used (e.g. time included).  In general, the concern he
> states is related to fingerprinting and kind of silly to worry about on
> a constrained device.

The concern raised in the draft is not so much applicable to the IoT
context but the inability for many IoT devices to put time into the
client hello is real.

> extensions may be specified in an update to the profile to improve them.

The entire IoT standardization work is about efficiency. Not sending
certificates, certificate chains, etc. is a big benefit when you deal
with low power radio technologies, like IEEE 802.15.4 or Bluetooth Smart.

> suites for PFS and PSK but that can wait until the down refs resolve?

RFC7251 is an informational document and a bit hard to avoid given that
this is the mandatory-to-implement algorithm / mode of operation used by
CoAP.

If the shepherd write-up indicates this document as a downref then there
shouldn't be any problem at all.

> changes to how TLS does its handshake.

Yes, I believe it would be useful to mention this aspect.

Independent of this draft I agree that using AES as a single construct
would be useful. TLS 1.2 introduced the ability to replace the hash
function used for key derivation and my understanding was that it is
possible to use an AES-based construct as a replacement for a hash
function for key derivation. Of course, one would have to demonstrate
that this is indeed secure as well. I would have to look at the details.

> addresses? Profile requires devices to support at least addresses, but

What do you think about the following change:

FROM:

"
   Clients are preconfigured with the address or addresses of servers
   (e.g., as part of the firmware) they will communicate with as well as
   authentication information:
"

TO:

"
Clients are provisioned with information about the servers they need to
initiate their DTLS exchange with and with credentials. This information
may be conveyed to clients as part of a firmware/software package or via
a configuration protocol. The following credential types are supported
by this profile:
"

> DNS?  (Page 9, second para in the PDF version).

You are referring to this paragraph:
"
   For IoT environments a simplifying assumption is made that
   the hint for PSK key selection is based on the domain name of the
   server.  Hence, servers SHOULD NOT send the "PSK identity hint" in
   the ServerKeyExchange message and client MUST ignore the message.
"

I guess you are right that this is a bit too restrictive. I therefore
suggest the following wording:

"
   If the hint for PSK key selection is based on the domain name of the
   server then servers SHOULD NOT send the "PSK identity hint" in
   the ServerKeyExchange message.
"

>  Last paragraph of
Ack.

> ---- Section 5.2 - same issue with inclusion of the cipher suite into

Ack.

> length for the two types of devices.

The suggested text sounds great. I will look at the 802.1AR spec to see
whether it indeed makes sense to include it. Another option would be to
reference the Zigbee IP specs since they also ran into that issue.

> unicast - not uni-cast (2nd para of section 3)
Ack.

> Instead: "A DTLS1.2 Profile for Constrained IOT Clients".

I have been wondering about the title myself as well. I was actually
thinking about extending the title to also include TLS since someone who
wants to run HTTP on an embedded device might want to go through the
same issues as with DTLS (even though HTTP is a bit larger than CoAP
implementation- and packet-size-wise).

The issue of focusing on *clients* is interesting because the document
indeed talks a lot about client side issues (assuming that the client is
the device that has limitations rather than the server). However, DTLS
is a protocol between two parties and hence it makes little sense to
only talk about the client when corresponding functionality has to be
available on the server side as well.

In a nutshell, I was (and I am still) not sure how to adjust the title
to best capture the content.

> the abstract isn't sufficient.

That's a difficult question, as you know. It is as "easy" as defining
what IoT is. The best I can offer is RFC 7228:
http://tools.ietf.org/html/rfc7228

Ciao
Hannes

>
>
> Later, Mike
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Michael StJohns <[email-masked]>
Date: Thu, 18 Sep 2014 12:03:15 -0400

On 9/18/2014 11:57 AM, Hannes Tschofenig wrote:
> my understanding was that it is
> function for key derivation.

You can use the AES-CMAC to replace SHA256-HMAC in the key derivation 
phase.  What you can't do is use AES-CMAC to replace SHA256 in the 
summary of the handshake that is then signed by the master key.  The 
summary of the handshake begins prior to having the key material you 
need, so you need to have an unkeyed hash.  At least as the protocol is 
currently spec'd.  So right now SHA256 is sort of required as a 
handshake infrastructure function.

Mike