Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement?

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 6 Aug 2015 12:00:26 +0200

Hi all, Hi Stephen,

I have sent the mail below to this mailing list in an attempt to solicit feedback from the DICE group after creating an issue in the issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34

I have also posted a message to the CFRG list, see

http://www.ietf.org/mail-archive/web/cfrg/current/msg07082.html

While I got a little bit of feedback on the CFRG list I am still unsure about how to proceed on this topic.

There does not seem to be strong interest in using ChaCha20 and Poly1305.

Currently, AES is in used in hardware of many embedded/IoT systems. It is also mandated in various standards, including radio technologies.

To my knowledge there is no hardware support for ChaCha20 and Poly1305 in chips today.

Requiring ChaCha20 and Poly1305 in addition to AES would be possible on paper but will lead to additional flash space.

What should we do?

Ciao

Hannes

Gesendet: Mittwoch, 15. Juli 2015 um 13:35 Uhr

Von: "Hannes Tschofenig" <[email-masked]>

An: "[email-masked]" <[email-masked]>, "Stephen Farrell" <[email-masked]>

Betreff: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement?

Stephen wrote:

(11) 21: Why not make RFC7539 a SHOULD or MUST right now? Doesn't it

seem like doing so now in a profile would be the right kind of timing?

And that might be our best bet for healing the CCM/GCM rift so I'd like

to check if the WG agree with that idea or not before we go to IETF LC.

(That might justify a separate thread.)

This is really a question for the group to think about. Any comments?

_______________________________________________

dtls-iot mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Rene Struik <[email-masked]>
Date: Thu, 6 Aug 2015 09:27:12 -0400

Hi Hannes:

I do not think there is any technical or practical reason to add support 
for ChaCha or Poly1305.

For very constrained devices, the required state is quite large, 
per-message key initialization cost is relatively high for short 
message, allowing starting processing of incoming packets
after computation of those per-message keys only, and ChaCha20 keys are 
256-bits. Most underlying transceivers already have AES on board, in 
hardware, and operate using 128-bit keys. Adding another mode does seem 
to impose cost, with unclear technical benefit, both on security and 
performance and implementation cost front.

On a side note: the security of Salsa20/20 has been quite well analyzed 
(see, e.g., [1]), but - to my knowledge - this has not been extended to 
ChaCha.

Best regards, Rene

[1] Ciphers - Salsa20 Secure Against Differential Cryptanalysis (Nicky 
Mouha, Bart Preneel, IACR ePrint 2013-328)

On 8/6/2015 6:00 AM, Hannes Tschofenig wrote:
> Hi all, Hi Stephen,
> I have sent the mail below to this mailing list in an attempt to 
> solicit feedback from the DICE group after creating an issue in the 
> issue tracker at http://trac.tools.ietf.org/wg/dice/trac/ticket/34
> While I got a little bit of feedback on the CFRG list I am still 
> unsure about how to proceed on this topic.
> Currently, AES is in used in hardware of many embedded/IoT systems. It 
> is also mandated in various standards, including radio technologies.
> Requiring ChaCha20 and Poly1305 in addition to AES would be possible 
> on paper but will lead to additional flash space.
> What should we do?
> Ciao
> Hannes
> *Gesendet:* Mittwoch, 15. Juli 2015 um 13:35 Uhr
> *Von:* "Hannes Tschofenig" <[email-masked]>
> *An:* "[email-masked]" <[email-masked]>, "Stephen Farrell" 
> <[email-masked]>
> *Betreff:* [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST 
> implement?
> Stephen wrote:
>

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 14:40:18 +0100

> performance and implementation cost front.

Sort-of. I've heard folks speculate that now that we're getting
rid of rc4 this ciphersuite is a good one to use if one does not
have AES h/w. And that seems reasonable to me. And were that
reasonable, then it'd also likely result in having a ciphersuite
in common between devices that do GCM and those that do CCM.

So the possible upside here is twofold: 1) it's a reasonable
ciphersuite for those who do not have AES h/w and 2) a way to
provide interop between devices that have GCM h/w and devices
that have CCM h/w.

I would say that that is enough of an upside to argue for
inclusion as a SHOULD-implement maybe.

It would be reasonable though to say that it'd be better to
wait a while until that ciphersuite is more widely used and to
then update this profile. The downside there is that there's
overhead in doing that and we might have missed the boat if
we don't add that ciphersuite now.

(Note: I'm not insisting on my preferred answer here, just that
the question be discussed which is happening)

S.

---

From: Rene Struik <[email-masked]>
Date: Thu, 6 Aug 2015 11:59:14 -0400

Hi Stephen:

I do not understand your reasoning, nor the relevance of RC4 (which is a 
stream cipher).

I would like to understand a little bit more why you think this would be 
a good fit in the (almost empty) universe of constrained nodes that do 
not have AES hardware on board. Wha problem are you trying to solve??

Rene