Subject: [Dtls-iot] AES-CCM nonces in DTLS records

From: "Kumar, Sandeep" <[email-masked]>
Date: Sat, 15 Nov 2014 03:44:05 +0000

Hi Hannes

I would like to point out one other improvement with AEAD mode ciphers (presently AES-GCM and AES-CCM) that could go into the profile draft.

Presently both RFC5288 and RFC6655 mention that the
The nonce_explicit MAY be the 64-bit sequence number.
However this only means that GenericAEADCipher.nonce_explicit field in the record layer is an exact copy of the sequence number (for DTLS: epoch||sequence number). This leads to a duplication of 8-bytes per record which can mean a lot for IEEE 802.15.4 networks.

ChaCha20 and Poly1305 based ciphersuite for TLS (draft-agl-tls-chacha20poly1305-04) does remove this duplication  by stating

When used in TLS, the "record_iv_length" is zero and the nonce is the

   sequence number for the record, as an 8-byte, big-endian number.

The question to you (and to the group) is if we can make a similar statement for improvement in AES-CCM preventing an 8-byte duplication per packet. Unfortunately this might mean that an IoT profiled DTLS using AES-CCM may not work with existing implementations unless there is some form of signaling (for example with an extension).

Regards
Sandeep

________________________________
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: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 17:59:44 -1000

On 14 Nov 2014, at 17:44, Kumar, Sandeep <[email-masked]> wrote:
> 
> this only means that GenericAEADCipher.nonce_explicit field in the record layer is an exact copy of the sequence number (for DTLS: epoch||sequence number). 

Indeed, that is one reason why GHC (RFC7400) works so well with DTLS 1.2.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 10:55:46 +0100

Hi Sandeep,

your observation is correct but I fear that changing the DTLS record
layer (since you are not proposing to chance the length of the nonce)
means to standardize a new ciphersuite in TLS.

Ciao
Hannes

On 11/15/2014 04:44 AM, Kumar, Sandeep wrote:
> Hi Hannes
> 
>  
> 
> I would like to point out one other improvement with AEAD mode ciphers
> (presently AES-GCM and AES-CCM) that could go into the profile draft.
> 
>  
> 
> However this only means that GenericAEADCipher.nonce_explicit field in
> the record layer is an exact copy of the sequence number (for DTLS:
> epoch||sequence number). This leads to a duplication of 8-bytes per
> record which can mean a lot for IEEE 802.15.4 networks.
> 
>  
> 
> ChaCha20 and Poly1305 based ciphersuite for TLS
> (draft-agl-tls-chacha20poly1305-04) does remove this duplication  by stating
> 
> The question to you (and to the group) is if we can make a similar
> statement for improvement in AES-CCM preventing an 8-byte duplication
> per packet. Unfortunately this might mean that an IoT profiled DTLS
> using AES-CCM may not work with existing implementations unless there is
> some form of signaling (for example with an extension).
> 
>  
> 
> Regards
> 
> Sandeep
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 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
>

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 25 Nov 2014 10:34:20 +0000

Hi Hannes

Indeed, to solve the nonce issue one would either require an extension or define a new cipher suite variations of existing cipher suites which clearly state that the nonce is the TLS sequence number. But as Carsten mentioned, GHC (RFC7400) seems to take away the problem where it really matters (i.e. IEEE 802.15.4 networks). I am okay if it is not in the profile anymore. ChaCha20+Poly1305 seems to have made a right choice and becoming more relevant in the embedded space anyways.

Regards
Sandeep

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2014 10:56 AM
> To: Kumar, Sandeep; [email-masked]
> Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records
>
> Hi Sandeep,
>
> your observation is correct but I fear that changing the DTLS record layer
> (since you are not proposing to chance the length of the nonce) means to
> standardize a new ciphersuite in TLS.
>
> Ciao
> Hannes
>
> > using AES-CCM may not work with existing implementations unless there
> > is some form of signaling (for example with an extension).
> >
> >
> >
> > Regards
> >
> > Sandeep
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > -- The information contained in this message may be confidential and
> > 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: Tue, 25 Nov 2014 11:39:04 +0100

Thanks for your response, Sandeep.

This statement below caught my attention in light of the AES-CCM vs.
AES-GCM discussion. Reading your sentence below gives me the impression
that instead of deciding about AES-CCM and AES-GCM we should instead
recommend ChaCha20+Poly1305.

Could you elaborate why you think ChaCha20+Poly1305 is becoming more
relevant in the embedded space?

On 11/25/2014 11:34 AM, Kumar, Sandeep wrote:
> ChaCha20+Poly1305 seems to have made a right choice and becoming more relevant in the embedded space anyways.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 25 Nov 2014 10:50:46 +0000

I would not go as far as recommending it right now.

There is a clear trend by the big-players in the industry to prefer ChaCha20+Pol1305 which will change the landscape in the coming years. Apple Homekit uses it http://devstreaming.apple.com/videos/wwdc/2014/701xx8n8ca3aq4j/701/701_designing_accessories_for_ios_and_os_x.pdf?dl=1 (Slide 98) and Google Chrome https://www.imperialviolet.org/2013/10/07/chacha20.html
The choice is due to performance but now compatibility will help push other players to move sooner too.

My 2 cents
Sandeep

> Sent: Tuesday, November 25, 2014 11:39 AM
> > ChaCha20+Poly1305 seems to have made a right choice and becoming
> more relevant in the embedded space anyways.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 12:25:35 +0100

Hi Sandeep,

I wouldn't call it a trend just because Apple does it in their new
products but quite clearly the cryptographic algorithms evolve over time
(btw, Curve25519 was listed as well).

Looking at the slides, which list the supported other radio
technologies, it is likely that some products will have to at least
support AES-CCM as well (for WiFi and/or for Bluetooth Smart).

As a product designer one has to make a conscious decision about the
expected product lifetime, degree of interoperability with other
devices, and the performance. A software-based crypto implementation,
which allows you to update the algorithm more easily, would give you a
potential performance hit but would score higher in the other categories.

When looking at teardowns of device it is clear that many of the IoT
devices are not as constrained as we often like portrait them. Hence,
having multiple implementations of different algorithms may not always
be an issue.

Maybe the recommendation in the document on this topic is to be aware of
the need to switch to different ciphers over the lifetime of the product
or to even support multiple ciphers (which calls for more flash and
potentially a faster CPU when a software-based implementation is used).
We have some text in there that talks about software updates but maybe
this specific issue could be highlighted.

Ciao
Hannes

---

From: Rene Struik <[email-masked]>
Date: Tue, 25 Nov 2014 10:55:02 -0500

Dear colleagues:

I thought DICE was about constrained devices and networks. For those 
devices where energy constraints are at play, this would almost surely 
require hardware-assisted implementation used for packet processing, 
simply to make sure that most of the energy is used for communications, 
not computation.)

(Admittedly, it does not help that the term "internet of things" has 
become almost meaningless and now [witness the reference to Apple] 
apparently even applies to $600 dollar devices talking to each other. 
Extrapolating this number to the 2011 marketing forecasts of 50 billion 
interconnected devices Cisco and Intel would make this a $30 trillion 
market [or about the 2013 GDP of the USA, China, and Japan combined]. 
Clearly, something must be wrong here...)

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Robert Cragie <[email-masked]>
Date: Tue, 25 Nov 2014 22:47:33 +0000

With hindsight, it may have been a mistake not to avoid the duplication 
of the sequence number and explicit nonce. However, at the time the aim 
was to keep the CCM cipher suite as close as possible to the GCM cipher 
suite.

Re. ChaCha and Poly - as Hannes says, things move on. CCM and GCM have 
been around a while now. That's not necessarily a reason to discard them 
now in consideration of something else.

Robert

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 26 Nov 2014 08:53:07 +0000

Hi Rene

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Tuesday, November 25, 2014 4:55 PM
To: Hannes Tschofenig; Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records

Dear colleagues:

I thought DICE was about constrained devices and networks. For those devices where energy constraints are at play, this would almost surely require hardware-assisted implementation used for packet processing, simply to make sure that most of the energy is used for communications, not computation.)

[> ] Constrained means different for different folks in the ecosystem, energy is only one axis. There will be devices which don't have that energy constraint (the famous light bulb) or are wired over a cheap twisted pair.

(Admittedly, it does not help that the term "internet of things" has become almost meaningless and now [witness the reference to Apple] apparently even applies to $600 dollar devices talking to each other. Extrapolating this number to the 2011 marketing forecasts of 50 billion interconnected devices Cisco and Intel would make this a $30 trillion market [or about the 2013 GDP of the USA, China, and Japan combined]. Clearly, something must be wrong here...)

[> ] Maybe you are confused, the reference was not about what Apple does in their $600 devices but what it is demanding from accessory developers (the IoT devices you might be thinking) that need to connect to those $600 devices.
And btw if you are really interested in making market calculations, take a second look at those marketing documents that mention 50 billion interconnected devices. They include anything from cars, trains to even cows (I am sure all of those are much more than $600).

regards
Sandeep

Best regards, Rene

Hi Sandeep,

be an issue.

Ciao

Hannes

My 2 cents

Sandeep

-----Original Message-----

To: Kumar, Sandeep; [email-masked]<mailto:[email-masked]>

dtls-iot mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Wed, 26 Nov 2014 08:55:52 -0500

Hi Sandeep:

The point of my note was to emphasize that the design has to be guided 
by the more constrained devices in a network (unconstrained devices and 
networks can fend for themselves). My cost figure (no matter how crude) 
illustrates that the average device cost has to be very low for 
marketing numbers to ever materialize, so constrained devices rule by 
numbers. Unfortunately, you seemed to have missed that point.

Rene

On 11/26/2014 3:53 AM, Kumar, Sandeep wrote:
>
> Hi Rene
>
> *From:*dtls-iot [mailto:[email-masked]] *On Behalf Of *Rene 
> Struik
> *Sent:* Tuesday, November 25, 2014 4:55 PM
> *To:* Hannes Tschofenig; Kumar, Sandeep; [email-masked]
> *Subject:* Re: [Dtls-iot] AES-CCM nonces in DTLS records
>
> Dear colleagues:
>
> simply to make sure that most of the energy is used for 
> communications, not computation.)
>
> */[> ] Constrained means different for different folks in the 
> ecosystem, energy is only one axis. There will be devices which don’t 
> have that energy constraint (the famous light bulb) or are wired over 
> a cheap twisted pair. /*
>
>
> Extrapolating this number to the 2011 marketing forecasts of 50 
> billion interconnected devices Cisco and Intel would make this a $30 
> trillion market [or about the 2013 GDP of the USA, China, and Japan 
> combined]. Clearly, something must be wrong here...)
>
> */[> ] Maybe you are confused, the reference was not about what Apple 
> does in their $600 devices but what it is demanding from accessory 
> developers (the IoT devices you might be thinking) that need to 
> connect to those $600 devices. /*
>
> */And btw if you are really interested in making market calculations, 
> take a second look at those marketing documents that mention 50 
> billion interconnected devices. They include anything from cars, 
> trains to even cows (I am sure all of those are much more than $600)./*
>
> *//*
>
> */regards/*
>
> */Sandeep/*
>
>
> Best regards, Rene
>
>
>         There is a clear trend by the big-players in the industry to prefer ChaCha20+Pol1305 which will change the landscape in the coming years. Apple Homekit uses ithttp://devstreaming.apple.com/videos/wwdc/2014/701xx8n8ca3aq4j/701/701_designing_accessories_for_ios_and_os_x.pdf?dl=1  (Slide 98) and Google Chromehttps://www.imperialviolet.org/2013/10/07/chacha20.html
>
>             To: Kumar, Sandeep;[email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik