[Cfrg] Can ChaCha20 be recommended for deployments?

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 22 July 2015 10:20 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D984C1AD1DB for <cfrg@ietfa.amsl.com>; Wed, 22 Jul 2015 03:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wSBDTt7aWzwT for <cfrg@ietfa.amsl.com>; Wed, 22 Jul 2015 03:20:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20C11AD16B for <cfrg@irtf.org>; Wed, 22 Jul 2015 03:20:33 -0700 (PDT)
Received: from [192.168.10.138] ([31.133.152.120]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4GND-1YzV4W3OZ1-00rmXd for <cfrg@irtf.org>; Wed, 22 Jul 2015 12:20:32 +0200
Message-ID: <55AF6E6E.6040101@gmx.net>
Date: Wed, 22 Jul 2015 12:20:30 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
References: <55AE1C08.6070002@gmx.net>
In-Reply-To: <55AE1C08.6070002@gmx.net>
OpenPGP: id=4D776BC9
X-Forwarded-Message-Id: <55AE1C08.6070002@gmx.net>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="FkWOl9dshbhh4mh5VC1ssPNXOFKHO22rv"
X-Provags-ID: V03:K0:oYaNmfn4L4w/qLZA9k6VT7JG9RN66Vsa5RKaYnRATUspXOjMZ9E JERggWWkYCkwK2B8XwgakoaWZihbSuR6nfDaGUEhtwk/YY8vQK9VxxTS4iRpvaDQ7Ft3h0M 8aUATNMDur/QhFIn432c9uv8eTqpSS7HPn3nfYUMhd1UJkEOo71w0xRsK4xBYNjIwUU2gLu LD8XlqAFT6I4Avbi9lElw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Li2nwbiLtqk=:pGNjGPPpPGK7HC/HP45MDC dJ1afZbVfspnO7iFI39ZDS6sRGN8woXnXoqi+R2enh2xSfOsavjfir+53VDJHcwVYmxn6EyPI wfmIcwDfH9DecbLl4TPoKfEht7bm0S6RU8lPysjME6FLYfoA/5hevsxS06aAkCuxPm4eTiADZ n/tqIIyGzPABld4edHVQiWH3E3rnIQD5DpHPjXDtGbcQfzRD/PTBY931tZ6yED380FGTyqrkP sgpYcaMBsv7OSP2rfK/8bsBGSo3B3WBaKzLHSyk7ywjMahDndwg4cNz1cfktmSpsCd1P/SNqi ZvBAab/Nf34jdblLSkwonS/I50b6txDCOXxa2/nRS43IcOR6XzgkeoLzNUbIZtWvp9x064ER3 CmtKEvlxCybQsanZjy9ScX8y8HI8wN9tMaUxEaaWp2vMPQ/DBNA71BT10P7QEMg39SM6jJXtB uh9Gqlm8b0dcNApBZGDKIKDfL02OMMpQw/dFXsB14woa/CbQaw+ijFOpLjiy6regW9dplhIOi BAuUHFTb6VRc0fe89blqD19uFDSuLTfVlQQGt6LiBjHWjBfq48M3O/ykzB3tKlQu3P6E/5CGc /9akHtKhUQocTOj0iBiASoWBf3YIQhHse1Cl++7lDmdAUd1K2ix58sdcqYWC2//ByLtN8LeRE 1Z5hzc0Onxiunt3B1oUiGxlnPqnNNF0uQskBOShwiungqXg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/N1pEUykI2CJjDsIQGdn8OfMz5zU>
Subject: [Cfrg] Can ChaCha20 be recommended for deployments?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 10:20:39 -0000

Hi all,

Stephen provided review review comments* to the 'TLS/DTLS Profiles for
the Internet of Things (IoT)' draft <draft-ietf-dice-profile> and
suggested that ChaCha20 and Poly1305 are included as a SHOULD or even a
MUST.

Currently, IoT devices often use AES in hardware. If this AES
implementation is not part of a separate crypto chip then it is part the
chip that implements the link layer protocol stack of a radio
technology. For example, Bluetooth Smart chips often have AES etc. in
hardware as part of their overall link layer stack implementation.

Unfortunately, due to the differences in nonce lengths used in AES
implementations for link layers (such as Bluetooth Smart) and nonce
lengths in TLS ciphersuites prevent easy re-use. Furthermore, chip
manufacturers are not always providing the APIs to access these crypto
functions for use with applications, i.e., only the link layer stack
uses the hardware crypto functions.

I believe that these points might give the impression that AES should
better be replaced with something else or enhanced with something else.
There may also be the desire to have a second algorithm in place in case
something goes wrong with AES, particularly considering that certain
types of IoT devices will have a very long lifetime.

On the other hand, AES has received a lot of review and ChaCha20 is
definitely not at that level. Furthermore, ChaCha20 seems to be designed
for software implementations and could therefore be added later to IoT
systems as part of a software update.

Today, there are very few software-based ChaCha20 implementations
available for IoT devices (such as the Apple Homekit) and I haven't seen
any hardware implementations yet.

Overall, I am not sure whether ChaCha20 and Poly1305 are useful
recommendations for IoT systems.

Does anyone in the CFRG have an opinion about this topic? What should we
recommend in the DTLS/TLS profile document?

Ciao
Hannes

*: http://trac.tools.ietf.org/wg/dice/trac/ticket/34