Subject: [Dtls-iot] DTLS profle draft

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 27 Mar 2015 16:40:50 +0000

Hi Hannes and Thomas

Thanks for the well-written document and taking into consideration all the comments.

However would like one final clarification:
Sec 6 states: "TLS server MUST return the decryption_error error message
   instead of the unknown_psk_identity since the two mechanisms exist
   and provide the same functionality."

However Sec 2 of RFC4279 states: "Alternatively, if the
   server wishes to hide the fact that the PSK identity was not known,
   it MAY continue the protocol as if the PSK identity existed but the
   key was incorrect: that is, respond with a "decrypt_error" alert."

Is the assumption that the server MUST continue the handshake if the psk_identity is not known and send the decryption_error on the Finished message?
Is that not opening up options for a DoS attacks on a constrained server?

----
Some other minor things that could be fixed:

-          The Fig4  client_certificate_type and server_certificate_type  can be shown clearly as extensions similar to as in Fig 8.

-          In Sec 4.2 Discovery and Reachability:
".....  Once it as been discovered,...."
as -> has

-          In Sec 6.1 mentions client identity but I guess you are referring to the PSK identity

-          Sec 9: "For cases where the server is constrained (but not the client) the client MUST implement RFC 5077"

Wondering how useful the mandatory statement is since "constrained" itself is a vague term.

-          Figure 11: shows 128 symmetric  and  283 bit-length ECC, but I could not find this relationship in the ENISA-2014 document. I have only seen it mapped to 256-bits. Wondering if this is a typo.

Overall great work.

Regards
Sandeep

Dr. Sandeep S. Kumar
Senior Scientist,
Data Science department,
Philips Research,
HTC36.p.22 Eindhoven, The Netherlands.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Mar 2015 17:13:34 +0200

Hi Sandeep,

thanks for reviewing the draft again.

A few remarks below:

On 03/27/2015 05:40 PM, Kumar, Sandeep wrote:
> Sec 6 states: “TLS server MUST return the decryption_error error message
> 
>    and provide the same functionality.”
> 
>  
> 
> However Sec 2 of RFC4279 states: “Alternatively, if the
> 
>    key was incorrect: that is, respond with a "decrypt_error" alert.”
> 
>  
> 
> Is the assumption that the server MUST continue the handshake if the
> psk_identity is not known and send the decryption_error on the Finished
> message?
> 

Where do you see the DoS attack potential here?

> -          The Fig4  client_certificate_type and server_certificate_type
>  can be shown clearly as extensions similar to as in Fig 8.

Good point!

> “…..  Once it as been discovered,….”
> 
> as -> has
> 
>  

OK.

> referring to the PSK identity

I should use the term PSK identity in the text.
Good catch!
> 
>  
> 
>  
> 
> -          Sec 9: “For cases where the server is constrained (but not
> the client) the client MUST implement RFC 5077”
> 
> Wondering how useful the mandatory statement is since “constrained”
> itself is a vague term.

It might make sense to expand this point a bit further.
I was thinking about the use of session resumption without server-side
state in the context of a constrained server that has to deal with a
number of clients and has limited amount of RAM / flash memory.

> 
>  
> 
> -          Figure 11: shows 128 symmetric  and  283 bit-length ECC, but
> I could not find this relationship in the ENISA-2014 document. I have
> only seen it mapped to 256-bits. Wondering if this is a typo.

The values of Figure 11 were copied from RFC 4492. I should make this
more explicit. The referenced ENISA document and other publications
recommend different values. For that reason I included those
publications by reference and point out that they roughly make the same
recommendations even though the details vary a bit.

What would, however, be useful to highlight is that these key lengths
refer to the long-term keys. The value of 128-bit symmetric (or the
equivalent for asymmetric crypto) is chosen conservatively under the
assumption that the lifetime of IoT devices is rather long.

This does, however, not necessarily mean that the key length of
Diffie-Hellman keys also needs to be as long as the long term keys. I
would say that this depends a bit on the data that is being protected. I
could imagine that shorter key length is acceptable given that leakage
of data that is several years old is less sensitive. Input on this issue
would, however, be appreciated. (I had a brief chat with Hugo about this
issue and will ask for his advice as well.)

> Overall great work.

Thanks.

Ciao
Hannes

> ------------------------------------------------------------------------
> The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or reproduction
> of this message is strictly prohibited and may be unlawful. If you are
> not the intended recipient, please contact the sender by return e-mail
> and destroy all copies of the original message.
> 
> 
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>