Subject: Re: [Dtls-iot] DTLS profle draft

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 May 2015 19:06:06 +0200

Hi Sandeep,

I am not sure whether I replied to your message already.

On 03/27/2015 05:40 PM, Kumar, Sandeep wrote:
>  
> 
> 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?
> 
> 

There are various types of DoS attacks that are possible in an IoT
deployment. I am most worried about amplification attacks. This attack
does not fall into that category.

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

>  
> 
> -          In Sec 4.2 Discovery and Reachability:
> 
> “…..  Once it as been discovered,….”
> 
> as -> has
> 
Fixed.

>  
> 
> -          In Sec 6.1 mentions client identity but I guess you are
> referring to the PSK identity
> 
> 
I added clarifying text and here is the updated paragraph:

"
   Note that [RFC4279] used the term PSK identity to refer to the
   identifier used to refer to the appropriate secret.  While
   'identifier' would be more appropriate in this context we re-use the
   terminology defined in RFC 4279 to avoid confusion.  RFC 4279 does
   not mandate the use of any particular type of PSK identity and the
   client and server have to agree on the identities and keys to be
   used.  The UTF-8 encoding of identities described in Section 5.1 of
   RFC 4279 aims to improve interoperability for those cases where the
   identity is configured by a human using some management interface
   provided by a Web browser.  However, many IoT devices do not have a
   user interface and most of their credentials are bound to the device
   rather than to the user.  Furthermore, credentials are often
   provisioned into hardware modules or into the firmware by developers.
   As such, the encoding considerations are not applicable to this usage
   environment.  For use with this profile the PSK identities SHOULD NOT
   assume a structured format (such as domain names, Distinguished
   Names, or IP addresses) and a bit-by-bit comparison operation MUST be
   used by the server for any operation related 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.
> 
>  

Here is the updated paragraph:

"
   For cases where the server constrained (but not the client) the
   client MUST implement RFC 5077 [RFC5077].  Note that the constrained
   server refers to a device that has limitations in terms of RAM and
   flash memory, which place restrictions on the amount of TLS/DTLS
   security state information that can be stored on such a device.  RFC
   5077 specifies a version of TLS/DTLS session resumption that does not
   require per-session state information to be maintained by the
   constrained server.  This is accomplished by using a ticket-based
   approach.
"

> 
> -          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.
> 
> 
Figure 11 is taken from RFC 4492. The challenge with providing good
numbers for key length is that it depends on lots of assumptions and the
referenced material explains those assumptions. Depending on the paper
the results are somewhat different.

> Overall great work.
Thanks.

Ciao
Hannes

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