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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 06 August 2015 13:40 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6A11B2FA1 for <dtls-iot@ietfa.amsl.com>; Thu, 6 Aug 2015 06:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clziFxB-qaOR for <dtls-iot@ietfa.amsl.com>; Thu, 6 Aug 2015 06:40:23 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026E21B2FBF for <dtls-iot@ietf.org>; Thu, 6 Aug 2015 06:40:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD1C2BE4C; Thu, 6 Aug 2015 14:40:21 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MnUgH_rKYuJ; Thu, 6 Aug 2015 14:40:21 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C014BDCA; Thu, 6 Aug 2015 14:40:20 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438868421; bh=G8YyiP4VdugOkqxJM0NTvyAuBMSipdEiN4S9FiRrVS4=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NsXXnAa4hDk6A05hyrzJTtRqpkNBSVJf/b1zELh95OYkkZexY5cOmEg3f+d/uibpD qPyx2EKglVpWjb39xsmEdwsuinc8MzJriT27OXIAULBfOy8WbBlQOYW/p0Fas2ex93 45nT4YfraYg7SluCnxFjtrkKrSqCg6KebVNXzm/U=
Message-ID: <55C363C2.2010005@cs.tcd.ie>
Date: Thu, 06 Aug 2015 14:40:18 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Rene Struik <rstruik.ext@gmail.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <55A6456E.4020806@gmx.net> <trinity-2aa15f2d-a0c6-4213-bd91-10a6d5ca06e0-1438855226547@3capp-gmx-bs27> <55C360B0.8070307@gmail.com>
In-Reply-To: <55C360B0.8070307@gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/zc4S8w578NtaqBoarH7KyG-OJxY>
Cc: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Subject: Re: [Dtls-iot] RFC 7539 (ChaCha20 and Poly1305) a SHOULD/MUST implement?
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 13:40:25 -0000


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" <hannes.tschofenig@gmx.net>
>> *An:* "dtls-iot@ietf.org" <dtls-iot@ietf.org>, "Stephen Farrell"
>> <stephen.farrell@cs.tcd.ie>
>> *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
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
>>
>> _______________________________________________
>> dtls-iot mailing list
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
> 
> 
> 
> 
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>