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

[Rene Struik <[e-mail]>]

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

On 8/6/2015 9:40 AM, Stephen Farrell wrote:
>
> On 06/08/15 14:27, Rene Struik wrote:
>> 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.
> 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.
>
>
>> 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
>>> 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" <[e-mail]>
>>> *An:* "[e-mail]" <[e-mail]>, "Stephen Farrell"
>>> <[e-mail]>
>>> *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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>>
>>>
>>> _______________________________________________
>>> dtls-iot mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
>>
>>
>> _______________________________________________
>> dtls-iot mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]