When used in TLS, the "record_iv_length" is zero and the non=
ce is the
   sequence number for the record, as an 8-byte, big-endian =
number.
Hi Sandeep,

On 11/15/2014 04:02 AM, Kumar, Sandeep wrote:

HI Hannes

Can you clarify if the silicon vendors are implementing AES-CCM or
plain AES in hardware (i.e. AES-ECB) with the CCM mode implemented in
software?

It is sometimes a bit hard to say whether functionality is implemented
in software or in hardware since everything is hidden on the chip.

Just take the Nordic Semiconductor Bluetooth Smart SoC (nRF51822)
https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822

Due to Bluetooth 4.1 specification it comes with AES-CCM support and the
firmware for this chip can be updated (and there are different versions
of the firmware available). What exactly can be updated is something I
don't know because the firmware image is provided by Nordic.

Of course, the main purpose of this chip is to run Bluetooth Smart-based
applications and there may not be enough space to run your entire IoT
software stack. You might have other radio technologies running on other
chips as well. As such, in your final product you might end up having
various places where you could run your cryptographic algorithms...

When I looked at the specifications to answer your question I actually
didn't find the needed info. Maybe I have not searched enough. I will
get in touch with the guys at Nordic to figure it out for this specific
example.

Your question is obviously quite good and I believe we should put more
text into the draft about this topic to give silicon vendors some
guidance about what to provide.

If it is the former, do you know if they are flexible
enough to implement AES-CCM with different nonce lengths. The reason
I ask is because AES-CCM in IEEE 802.15.4 uses a nonce length of
13-octets while DTLS uses 12-octets. I have heard of some15.4 chips
that hard-code (in hardware) the 13-octet nonce length making it
useless for DTLS.

Is the issue caused by IEEE 802.15.4 or by Zigbee IP?

Ciao
Hannes

Regards Sandeep

-----Original Message----- From: dtls-iot
[mailto:dtls-iot-bounces@ietf.org] On Behalf Of Hannes Tschofenig 
Sent: Friday, November 14, 2014 9:58 AM To: Russ Housley;
dtls-iot@ietf.org Cc: Dorothy Gellert; Zach Shelby Subject: Re:
[Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014

Hi Russ,

thanks for bringing this up.

The ciphersuites selected for the DTLS profile draft have been
heavily influenced by the work done in the CORE working group.

We have been telling silicon partners that they should put AES-CCM
into their chips and they have indeed following that
recommendation.

I believe, however, that this is not a problem as such since the
UTA work really has a different scope - they focus on
Web/Messaging/Email rather than the IoT space. I sent a mail to
their list to request the title to be adjusted.

Ciao Hannes

On 11/12/2014 01:37 AM, Russ Housley wrote:

DICE document requires TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  I

have no problem with that choice.  It makes a lot of sense for
small devices.

The HTTPbis is also taking a path that requires an AEAD
algorithm.  It would

be really nice if the two groups came to a place that allowed
interoperability, but HTTPbis seems to be on a path for AES-GCM.
AES-CCM is better for small devices.

It seems to me that the two groups should talk to each other
before WG

Last Call is over.

Russ

_______________________________________________ dtls-iot mailing
list dtls-iot@ietf.org 
https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________ 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
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
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

On 11/25/2014 11:50 AM, Kumar, Sandeep wrote:

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

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Tuesday, November 25, 2014 11:39 AM
To: Kumar, Sandeep; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records

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.

________________________________
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
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
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

On 11/25/2014 11:50 AM, Kumar, Sandeep wrote:

I would not go as far as recommending it right now=
=2E

There is a clear trend by the big-players in the industry to prefer ChaCh=
a20+Pol1305 which will change the landscape in the coming years. Apple Ho=
mekit uses it http://devstreaming.apple.com/videos/wwd=
c/2014/701xx8n8ca3aq4j/701/701_designing_accessories_for_ios_and_os_x.pdf=
?dl=3D1 (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 oth=
er players to move sooner too.

My 2 cents
Sandeep

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Tuesday, November 25, 2014 11:39 AM
To: Kumar, Sandeep; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records

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 c=
hoice and becoming

more relevant in the embedded space anyways.

________________________________
The information contained in this message may be confidential and legally=
 protected under applicable law. The message is intended solely for the a=
ddressee(s). If you are not the intended recipient, you are hereby notifi=
ed that any use, forwarding, dissemination, or reproduction of this messa=
ge is strictly prohibited and may be unlawful. If you are not the intende=
d recipient, please contact the sender by return e-mail and destroy all c=
opies of the original message.

_______________________________________________
dtls-iot mailing list
d=
tls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot

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 ti=
me
(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<=
/o:p>
devices, and the performance. A software-based crypto implementation,<=
o:p>
which allows you to update the algorithm more easily, would give you a=

potential performance hit but would score higher in the other categori=
es.

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,<=
o:p>
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 produ=
ct
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

On 11/25/2014 11:50 AM, Kumar, Sandeep wrote:
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 Ch=
aCha20+Pol1305 which will change the landscape in the coming years. App=
le Homekit uses it http://devstreaming.apple.com/videos/wwdc/2014/701xx8n8ca3aq4j/701/701_de=
signing_accessories_for_ios_and_os_x.pdf?dl=3D1 (Slide 98) and Google C=
hrome h=
ttps://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

-----Original Message-----
From: Hannes Tschofenig [=
mailto:hannes.tschofenig@gmx.net]
Sent: Tuesday, November 25, 2014 11:39 AM
To: Kumar, Sandeep; dtls-iot@ietf=
.org
Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records

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 impressio=
n
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 mo=
re
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.

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

_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org<=
/pre>
https://www=
.ietf.org/mailman/listinfo/dtls-iot

-- 
email: rstruik.ext@gmail.com<=
/a> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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

On 11/25/2014 11:50 AM, Kumar, Sandeep wrote:
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

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Tuesday, November 25, 2014 11:39 AM
To: Kumar, Sandeep; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] AES-CCM nonces in DTLS records

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.

________________________________
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
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
Hi all,

I went through the review comments and the discussions on the list and
added issues to the tracker. You can find the complete list here:
https://tools.ietf.org/wg/dice/trac/report/1

- Issue#12: Updated text for the PFS section
https://tools.ietf.org/wg/dice/trac/ticket/12

- Issue#16: New section explaining how to deal with constrained servers
(as discussed on the list)
https://tools.ietf.org/wg/dice/trac/ticket/16

- Issue#15: New section giving guidance on timeouts
https://tools.ietf.org/wg/dice/trac/ticket/15

- Issue#13: New section with key length recommendations
https://tools.ietf.org/wg/dice/trac/ticket/13

- Issue#11: Question about applicability of text to TLS
https://tools.ietf.org/wg/dice/trac/ticket/11

- Issue#14: New section about the signature algorithm extension
https://tools.ietf.org/wg/dice/trac/ticket/14

- Issue#17: AES-CCM nonces in DTLS records.
https://tools.ietf.org/wg/dice/trac/ticket/17

- Issue#18: AES-CCM: 12-octet or 13-octet nonce
https://tools.ietf.org/wg/dice/trac/ticket/18

- Issue#19: Issue about AES-CCM vs. AES-GCM
https://tools.ietf.org/wg/dice/trac/ticket/19

I suspect that issue #16 and #11 could trigger some discussion. Issue
#19 does not have a resolution yet.

I thought that the tracker would send mails to the list but it did not
seem so. Instead of copying all the issues to the list take a look at
the tracker.

I am planning to release a new draft snapshot late next week.

Ciao
Hannes

PS: I am also in the process of incorporating various editorial
suggestions. Here is the draft snapshot:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-=
profile/draft-ietf-dice-profile-06.txt

_______________________________________________
dtls-iot mailing list
d=
tls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot