Re: [Cfrg] [TLS] 3DES diediedie

Derek Atkins <derek@ihtfp.com> Tue, 06 September 2016 20:44 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985A112B37C for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 13:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com
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 9XdiSK13XnLV for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 13:44:46 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E20E12B069 for <cfrg@irtf.org>; Tue, 6 Sep 2016 13:44:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7E4C8E2045; Tue, 6 Sep 2016 16:44:45 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21931-01; Tue, 6 Sep 2016 16:44:43 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C0A73E2038; Tue, 6 Sep 2016 16:44:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1473194683; bh=d2MClU3yJ2QfPMkIKEKDigEipdTc9yCuNk+++9XXQuc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=q3W5q+aEBCuhRj+6LhaWmCHGzDtuKpvF0RpWQjd3+L4MJ8v14KD4gMWpDNhj9zEXO ohhlz2wtL5zGYiOVytUv/GkQkbBbDR72iBqNFQiEzMGkSeUDZ8HZ3dchy99IlHaUOR 9j30LpHVQ1Xv892SDTt0r7QKLon2RCrDWY736McE=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u86KigYc023487; Tue, 6 Sep 2016 16:44:42 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Joachim Strömbergson <joachim@secworks.se>
References: <20160906114030.18292816.41703.89024@ll.mit.edu> <57CEAE6F.1040608@secworks.se>
Date: Tue, 06 Sep 2016 16:44:42 -0400
In-Reply-To: <57CEAE6F.1040608@secworks.se> ("Joachim Strömbergson"'s message of "Tue, 06 Sep 2016 13:54:23 +0200")
Message-ID: <sjmeg4wvjut.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/dAHKMJIGhEOLNV3kxyfMab3-fMo>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Hilarie Orman <hilarie@purplestreak.com>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://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: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 20:44:48 -0000

Hi,

Joachim Strömbergson <joachim@secworks.se> writes:

> Aloha!
>
> The point is that you _can_ run the highly standardized AES cipher and
> meet cost, power consumption and use case (including response times,
> performance) requirements on modern, low cost 32-bit MCUs even for
> highly constrained IoT solutions.
>
> Thus the need for smaller and cheaper ciphers that are less well known,
> less proven, not generally available in peers, hosts, servers are not
> needed.
>
> Yes, you can find solutions where ultra light ciphers are needed, but
> thanks to Moore's law those cases has rapidly diminished. More so than
> people in general seem to understand.

I'm afraid I have to disagree here.  What's it's done is pushed
yesterday's computation capabilities into smaller and smaller devices,
lower and lower on the food chain.  C.f. my previous email about a light
bulb.  Cost is definitely a concern, as well as power and performance.

So while yes, we can say "let's use an ARM Cortex Mx", that really
doesn't work in all cases.  So sure, we can wait yet another decade for
Moore's law to catch up with today's smart devices, but I suspect then
we'll have yet another class of even smaller devices.

> The implementation of the cipher is rarely the components that make or
> break the design. And in terms of development cost, deployment cost and
> the effort to convince buyers to trust something that is not AES, they
> all increase. Things you also need to account for at system design time.

True..  but it can certainly be a factor.

> Yours
> JoachimS

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant