Re: [TLS] [Cfrg] 3DES diediedie

Tony Arcieri <bascule@gmail.com> Thu, 08 September 2016 16:28 UTC

Return-Path: <bascule@gmail.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 B86BD12B1C7 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 09:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8WKjLhvBzlyz for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 09:28:48 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 9FA9A12B1BB for <tls@ietf.org>; Thu, 8 Sep 2016 09:28:48 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id 31so45286123uao.0 for <tls@ietf.org>; Thu, 08 Sep 2016 09:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJbuZKFW8dhCv9hEa4JVDHGHfn8R1flPHCitjCysgnU=; b=U1MSik3eFzE9rAF6QDP/ITjcShhvhcJRFV6KJHSHUy0vuFeK0h7zkAZiHTnRwGBvtY dfQmR/nPpiirlCYEejlqGzXjals0ygg42aTV7Ne5QXdWWNFflEIxn4Npjh+MQxV6Y+gK eQlDarwgt4KfiN8EfxVMGg6LPYG/mXMTJMlFAVCpvOEJRAgBYB7r/KL+yXVq955bahKy DyXilTy9iQNnPsi/lu5WuYEHJJdLgCMWm8opIvLycIpn2oOywOz1hyM7hfsClkFFtfam KDR5XMT9yTLIkOKrfQOP1ImLNwJ20eeDR0VbFFwk8ZVN5k4+aBL9pm+quzcRZkDb4DuH 9phQ==
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=wJbuZKFW8dhCv9hEa4JVDHGHfn8R1flPHCitjCysgnU=; b=OqJ5CqHw5LI1s0XZuBHAzY0dmpszNIwoHZffzl4DrioqOhp5UdgWAz40XNVDmTRRmm 7yT7dDfFjM7Xr0Q7RaKlE37nN6NvJfvckX8eAZEWDIljYr0gnRiZzscgdDRAa0CAPEGf bmnWsIF0w3InsZlsbALXBr3VBSt6Otti6ylvwHOX2mHGEJJQg6mJ9dRBjA1ogrq0YvH6 V8kbkSvtvV3h89LGRYLLawbQbkREM5szSBVF669qcY2DM7wpiJM5mXq5kTe2VEb2uesK iwpS1XEbBl3rkaG8FOyE+ZSkrjxHkuXrEw4lqYW5cQz5+neU4z4UUHI7G4boAlPCaeD7 IbGQ==
X-Gm-Message-State: AE9vXwO19vW4MtTijFhH9uY5EOtbZ3NiEJg3tWzRHRvKG2VFxVjMeJHxOdqwsGZ/KdyNct7bMMr8W6oOeaY8HQ==
X-Received: by 10.176.2.178 with SMTP id 47mr458865uah.10.1473352127810; Thu, 08 Sep 2016 09:28:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.79.90 with HTTP; Thu, 8 Sep 2016 09:28:26 -0700 (PDT)
In-Reply-To: <sjmzinitozf.fsf@securerf.ihtfp.org>
References: <m2lgzcyhxi.fsf@bos-mpeve.kendall.corp.akamai.com> <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com> <CABrd9STOCbBo=g22XySRnWofHwVZkrC-ripZY38yLRZV2kQh3A@mail.gmail.com> <sjminu8vk1t.fsf@securerf.ihtfp.org> <1473221674611.89839@cs.auckland.ac.nz> <CAHOTMVKJJAOz+a0d6jej2mYpM9LiBnt65XtYVVTH6dKzN_UCxA@mail.gmail.com> <sjmzinitozf.fsf@securerf.ihtfp.org>
From: Tony Arcieri <bascule@gmail.com>
Date: Thu, 08 Sep 2016 09:28:26 -0700
Message-ID: <CAHOTMVLJgMPOCTWhBmYW2x0bhHBfcxr9FtKm5jWEJ0tq2utqYw@mail.gmail.com>
To: Derek Atkins <derek@ihtfp.com>
Content-Type: multipart/alternative; boundary="001a113cd3ca35128a053c0186b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QOEGaijAk3Trz-Autk8me2HGuNE>
Cc: "cfrg@irtf.org" <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: Thu, 08 Sep 2016 16:28:52 -0000

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins <derek@ihtfp.com> wrote:

> So they are finally up to 80-bit security?  Woohoo!
> That makes me feel so safe.
>

1024-bit RSA is certainly less than ideal, but certainly better than
nothing, which was the claim about devices in this class.

Comparisons with symmetric cryptography aren't exactly fungible like that
either: though I personally consider 1024-bit RSA keys to be weak, to my
knowledge one has not been factored successfully by the general public.

Payments are a very poor example..  Several seconds per transaction?
> That's not usable performance.  Look at all the pushback from consumers
> that have been happening since the changeover to chip cards in the US
> this past year.
>

The cryptography is not the bottleneck in this case: poor implementations
of the protocol are. Use the same card for an NFC transaction (provided
it's capable) and the delay will be considerably less.

Also, an asymmetric primitive is something you'd use to exchange keys and
sign transcripts for session initialization, after which all subsequent
communication is symmetric. Does a second of handshaking actually matter if
all subsequent communication is hardware accelerated symmetric
cryptography? (I'm sure it might for some, but won't for many others)

The real point is that if verticals within the "IoT space" were to
standardize on a particular set of asymmetric primitives and ship them en
masse like the payments industry did, economies of scale can drive the
costs down to the levels they deem acceptable. But they seem unwilling to
do the up-front development work and want to continue using the MCUs
they're already using, many of which have no crypto accelerators
whatsoever...