Re: [TLS] [Cfrg] 3DES diediedie

Ben Laurie <benl@google.com> Mon, 05 September 2016 18:25 UTC

Return-Path: <benl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030BD12B445 for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 11:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9r8gaROfJ-2x for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 11:25:42 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B16012B0A4 for <tls@ietf.org>; Mon, 5 Sep 2016 11:25:42 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id f76so82594314vke.0 for <tls@ietf.org>; Mon, 05 Sep 2016 11:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C5Wm5LsyBFd9JhyxTOPvRA6GYGX4im7WHdoJ+kBGN9Q=; b=kY4hXoM6XkzL9MWwIR1ARm1yQjf4TOsFVlwClKFnHdb8VV1MBLSBFM44J3n0g/ah2l EwDXPTSp8VB3EVkB3eTx+cispvPmg2p0z0sckm+93fJoaJRPL31OkI+xoCGhrO+AeDUQ GqLUy0DKPrR1zNvNM+jN3Y0662AitDUZpwNFTeLynTZBpck3HzapvEOHvIePJRIEthVC lEq4Ilj2iikdCiv14AM5jqDLhYGMwVPZR1uS46TFjztjs5dcJzyFEpRXdSa0ualACvXK lRl9GRjohYUbUrZ/FPSF7FAQVXzHI0ZFiy5F266EvzHs2DRkgdzjtZqyFPNL2K2N4T+8 xa8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C5Wm5LsyBFd9JhyxTOPvRA6GYGX4im7WHdoJ+kBGN9Q=; b=Lln8gvXYHtIX7x/WHs6RkBO/6pnW9BTXnMbI5r0vL/UvLhzHD24QK/CJqvypRfTm49 aaYTWe8WldxIju+DuBitSPBKYVRqy6EO8IXy4tGEsZ+Uhk9Y6crJLnyZNsNIYc0R0MxI FCs7iG/dUfvfeWDKeES9dYdsdIZ0y3l+moL5G5U4BK9jlvJUn/k80XmPiJM/iAJHnjIZ 4T9qQMIf+ln5kyWEyPfr7eTCTlp3vIZiR5zhViYyAsTAxx4GEzWQ7kZ6ZL+8zbRi0oht td01x60028ZRaoLABuJ2Fr13PBYkJOHVTUqBHNvcuSqG5TGlGclJc8NY5zwQqoELtoRV 5Xlw==
X-Gm-Message-State: AE9vXwNb0rfx2wh7w7Cd6QCnoIDt5d8mRfAzsM91v1V0EhmU9Neqv/n8gbYImJDHw+ej07tVV+0l1D6QZesHdLTS
X-Received: by 10.31.21.79 with SMTP id 76mr22444630vkv.135.1473099941172; Mon, 05 Sep 2016 11:25:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.148.11 with HTTP; Mon, 5 Sep 2016 11:25:39 -0700 (PDT)
In-Reply-To: <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com>
References: <m2lgzcyhxi.fsf@bos-mpeve.kendall.corp.akamai.com> <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com>
From: Ben Laurie <benl@google.com>
Date: Mon, 5 Sep 2016 19:25:39 +0100
Message-ID: <CABrd9STOCbBo=g22XySRnWofHwVZkrC-ripZY38yLRZV2kQh3A@mail.gmail.com>
To: Hilarie Orman <hilarie@purplestreak.com>
Content-Type: multipart/alternative; boundary=001a1142f196b6b0a3053bc6ce67
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dkecsUxNaRovZtqVYmPyq-NGGJk>
Cc: cfrg@irtf.org, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2016 18:25:45 -0000

On 31 August 2016 at 20:48, Hilarie Orman <hilarie@purplestreak.com> wrote:

> >  From: Brian Sniffen <bsniffen@akamai.com>
>
> >  >>  From: Derek Atkins <derek@ihtfp.com>
> >  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
> >  >
> >  >>  "Steven M. Bellovin" <smb@cs.columbia.edu> writes:
> >  >
> >  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
> >  >>  > crypto" is a hangover from several years ago. It was once true;
> for
> >  >>  > the most part, it isn't today, but people haven't flushed their
> cache
> >  >>  > from the old received wisdom.
> >  >
> >  >>  This is certainly true for AES, mostly because many small chips are
> >  >>  including AES accelerators in hardware.  It's not quite true for
> public
> >  >>  key solutions; there are still very small devices where even ECC
> takes
> >  >>  too long (and yes, there are cases where 200-400ms is still too
> long).
> >  >
> >  >>  > It pays to look again at David Wagner's slides from 2005, on
> sensor
> >  >>  > nets and crypto:
> >  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
> >  >>  >
> >  >
> >  > Unattended sensors with wifi present an unsolved crypto problem.  They
> >  > can last 10 years on an AA battery without crypto, probably well less
> >  > than a year if they have to do any kind of encryption.  These things
> >  > will be everywhere, providing the data that will underly all kinds of
> >  > decision-making.
>
> >  Assuming there are *some* integrity requirements for the data, and that
> >  they are deploying 32-bit ARM with AES support (stipulating that ~every
> >  CPU will have AES support in a few years, as ~every CPU sold does
> >  today), we're talking about *either* an ECDHE negotiation every few
> >  months or a pre-shared key, good for ten years.
>
> >  AES-GCM with hardware support compares favorably to SHA-2 without
> >  hardware support, so if they've been able to last 10 years before, they
> >  should do just fine in the future.  The old devices won't last forever,
> >  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
> >  for ten years after 1.3 is out.
>
> >  -Brian
>
> >  > Although much of the solution may lie in hardware innovation, the
> >  > world really does need minimal crypto algorithms.
> >  >
> >  > Hilarie
> >  >
>
> An ARM is far too much hardware to throw at "read sensor/munge data/send
> data".
>

The question is not "how much hardware?" but "price?" - with  ARMs
including h/w AES coming in at $2 for a single unit, its hard to explain
why you\d want to use a less powerful CPU...


>
> Hilarie
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>