Subject: [Dtls-iot] Fwd: New Draft Notification - [draft-raza-dice-compressed-dtls-00]

From: Shahid Raza <[email-masked]>
Date: Wed, 2 Apr 2014 21:22:05 +0500

It would be great if IETFers in the DICE WP provide us reviews on this draft. 

/Shahid

Begin forwarded message:

> From: Shahid Raza <[email-masked]>
> Subject: [Dtls-iot] New Draft Notification - [draft-raza-dice-compressed-dtls-00]
> Date: 21 Mar 2014 15:13:18 GMT+5
> To: [email-masked]
> Cc: Shahid Raza <[email-masked]>, "Olivier Dupont \(odupont\)" <[email-masked]>, Hossein Shafagh <[email-masked]>
> 
> Dear All,
> 
> A new draft is submitted to the DICE Working Group. 
> http://tools.ietf.org/html/draft-raza-dice-compressed-dtls-00
> 
> This work provides a lightweight CoAPs by compressing the underneath DTLS protocol with 6LoWPAN header compression mechanisms.  With DTLS header compression we achieve energy efficiency by reducing the message size, since communication requires more energy than computation. Also,  it avoids 6LoWPAN fragmentation that is applied when the size of datagram is larger than the link layer MTU. Our compressed DTLS maintains true End-to-End (E2E) security between resource constrained hosts in 6LoWPAN networks and typical Internet hosts that use uncompressed CoAPs.
> 
> Regards
> Shahid
> 
> ---------------------------------------------------------------
> Shahid Raza
> PhD, Senior Researcher
> Networked Embedded Systems group
> Swedish Institute of Computer Science (SICS)
> SICS Swedish ICT, Stockholm, Sweden
> Ph. No. +46 768831797
> http://www.shahidraza.info
> 
> Research Interests: IoT, Security, WSNs
> ---------------------------------------------------------------
> 
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Michael StJohns <[email-masked]>
Date: Thu, 03 Apr 2014 13:52:32 -0400

> It would be great if IETFers in the DICE WP provide us reviews on this 

A couple of quick notes:

While the DICE folks should certainly look at this, given that this is 
all about 6Lowpan header compression, it may be more useful to move it 
forward in the 6lowpan group.  Among other reasons - the expertise to 
evaluate this is more about the 6lowpan than it is about DTLS.

During the last TLS f2f meeting, and given current discussions on the 
TLS mailing list, it's unclear that compression is on the table for the 
future of TLS due to various attacks related to compression.  This may 
or may not impact consideration of this draft.

With respect to the document approach related to DTLS there are a few 
possible gotchas:

1) Cipher Suite compression - this ties the draft to a specific COAP 
required cipher suite - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as a 
default.  That makes that suite somewhat mandatory to implement, and 
leaves some issues with respect to how to deal with regional cipher 
suites requirements as well as futures.  Given the relatively small size 
of a cipher suite spec (2 bytes), and given a possible loss of 
flexibility, it's unclear that this is a reasonable field to compress.

Also, that suite uses - I believe - the HMAC-SHA-256 as the PRF.  I 
understand the goal is to get to an IOT implementation that only needs 
to implement the block encrypt function of AES so that suite may be the 
wrong suite to specify as a default.

2) Compression Methods compression - given the discussion on the TLS 
list it may be useful in the DICE DTLS profile to just ban TLS style 
compression for DICE DTLS.  That's a separate discussion from the 
6lowpan dtls header and protocol compression.

3) Section 4 - next to last paragraph - "The length field of the 
handshake headers is always omitted as it can be deduced from the lower 
layers" - I don't think I have a big problem with deducing length from 
6lowpan even though that's a layer violation, but I would object to the 
need to look at the 802.15.4 header as that's far outside the IETF's 
scope and changes that happen there could be problematic.  Maybe note 
that 802.15.4 has a header compression scheme, and that it losslessly 
recovers the IPv6 6lowpan datagram and leave it at that?

4) This document needs a section describing when and in what order 
compression and decompression and other calculations  happen -

e.g.   form the normal DTLS datagram, calculate the MIC, THEN compress 
the dtls headers THEN calculate the UDP checksum THEN compress the UDP 
headers then compress the IP headers.

Mike

>
> Begin forwarded message:
>
>> *From: *Shahid Raza <[email-masked] <mailto:[email-masked]>>
>> *Subject: **[Dtls-iot] New Draft Notification - 
>> [draft-raza-dice-compressed-dtls-00]*
>> *Date: *21 Mar 2014 15:13:18 GMT+5
>> *To: [email-masked] <mailto:[email-masked]>
>> *Cc: *Shahid Raza <[email-masked] <mailto:[email-masked]>>, 
>> "Olivier Dupont \(odupont\)" <[email-masked] 
>> <mailto:[email-masked]>>, Hossein Shafagh <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> Dear All,
>>
>> This work provides a lightweight CoAPs by compressing the underneath 
>> DTLS protocol with 6LoWPAN header compression mechanisms.  With DTLS 
>> header compression we achieve energy efficiency by reducing the 
>> message size, since communication requires more energy than 
>> computation. Also,  it avoids 6LoWPAN fragmentation that is applied 
>> when the size of datagram is larger than the link layer MTU. Our 
>> compressed DTLS maintains true End-to-End (E2E) security between 
>> resource constrained hosts in 6LoWPAN networks and typical Internet 
>> hosts that use uncompressed CoAPs.
>>
>> Regards
>> Shahid
>>
>> *SICS Swedish ICT,*Stockholm, Sweden
>> Ph. No. +46 768831797
>> http://www.shahidraza.info <http://www.shahidraza.info/>
>>
>> [email-masked] <mailto:[email-masked]>