Re: [Cfrg] [TLS] 3DES diediedie

Ira McDonald <blueroofmusic@gmail.com> Wed, 07 September 2016 00:28 UTC

Return-Path: <blueroofmusic@gmail.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 B67BF12B450 for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 17:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 4gOwFCL3-CVy for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 17:28:34 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 AB6D212B428 for <cfrg@irtf.org>; Tue, 6 Sep 2016 17:28:34 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id m11so380251oif.1 for <cfrg@irtf.org>; Tue, 06 Sep 2016 17:28:34 -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=bWO/HRnKZ4XuB7mjDbvxH02WJc1WKkedYBTkWK6bf5Q=; b=rQqZTTUs8OkPcZTNBdhySM4mGZOmYnY/TbKAqWwe6EANtgwy4tq4TRCd6kGdmvoSxM DYbImCX48yhW8Fp9y70fm6j8nQIY0ge4wVHTuOhIPbKXXc1xYo3YPE6NOC180F6qgzrP zXdIIp9GlrLoiO+Bvkoes3eakk/noJSQwI3mvNtMT+xkzY4cDpOBFSqtGIniE5WLtrk8 fbm+K+i+N1h5Z0kQh3Ghw5KjPiGXGowlesOAsXjpQmA8DaFQ0gws5z59WDVJ+3W7gykE eayIodFZX5TW7+g4EO34jATl2yHuA7kEQ0F8VudrQVaJQ3yH5uf7L4xIuya+MkIQHw9N nKfw==
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=bWO/HRnKZ4XuB7mjDbvxH02WJc1WKkedYBTkWK6bf5Q=; b=GaSkfjvd/6nw50F8VHPLimKXyJkZUSWHQQ8tvzhXZ5nL4YzoxX63hmWtgS27zkiAHS lMtGqvl66yYvUNff1tUWnRw57Zax0S8F9zz+ysRN/1NSnsHmJKY6Imv2ye80bkBBR+rK VTvbRYncCP7OSrG3zPwxmoKpIugAXd6LEbreVcVs7Sf2u+wWSmUOnAAMw9L7MngaEJaX MDVYmvF0o+owT5DbsDMn0pjTH52aND6VWNtLdMjEOfZiLoh2gsUztn2Az3CCrianS8pK /bUFsSi5MtqhNbqpFMYpnETdbJU6KunZikkQBjqu/7PiUCMRaqL4nurnlt2U9bfXXPKl EKMA==
X-Gm-Message-State: AE9vXwPxrMMAwxVpPtdop1xKaQZUSQC6W2a4V2HEr4ljXGN5ID7XImicOsxrGzr8H8BUqrYEMvaRSCvsmPQTBw==
X-Received: by 10.36.189.68 with SMTP id x65mr2162878ite.97.1473208113961; Tue, 06 Sep 2016 17:28:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.11.67 with HTTP; Tue, 6 Sep 2016 17:28:13 -0700 (PDT)
In-Reply-To: <201609062017.29697.davemgarrett@gmail.com>
References: <m2lgzcyhxi.fsf@bos-mpeve.kendall.corp.akamai.com> <CABrd9STOCbBo=g22XySRnWofHwVZkrC-ripZY38yLRZV2kQh3A@mail.gmail.com> <sjminu8vk1t.fsf@securerf.ihtfp.org> <201609062017.29697.davemgarrett@gmail.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Tue, 06 Sep 2016 20:28:13 -0400
Message-ID: <CAN40gStbOtyfHkFuS5iXhFwm7K3RNwP6ts7wQ3LCbQ7W1OJ6ZA@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>, Ira McDonald <blueroofmusic@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c19e252502159053bdffe25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0lr30CA5UvsO_nR3OolTBwaI06k>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.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: Wed, 07 Sep 2016 00:28:37 -0000

Hi Dave,

Might work for lightbulbs.  Doesn't work for automotive sensors and ECUs,
which already have proprietary security (undisclosed algorithms) and badly
need to have standards-based security.  Cents in cost really matter here.
ARM CPUs are not and will not become the only answer in automotive.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434


On Tue, Sep 6, 2016 at 8:17 PM, Dave Garrett <davemgarrett@gmail.com> wrote:

> On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote:
> > Ben Laurie <benl@google.com> writes:
> > >     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...
> >
> > Because this is a light bulb that sells for $6-10.  Adding $2 to the
> price
> > is just completely unreasonable.  The price point needs to be pennies.
> > Note that this is just one example, but yes, these level of products are
> > getting "smarter" and we, as security professionals, should encourage
> > "as strong security as possble" without getting the manufacturers to
> > just say "sorry, too expensive, I'll go without."  (which is,
> > unfortunately, exactly what's been happening)
>
> Personally, I'd just say "stop putting chips in light bulbs", instead.
> Companies making these things are unfortunately just not going to be making
> good security decisions. Bad or no security is cheaper than competent
> security, and selling light bulbs with bad security is not illegal. We'll
> be more successful focusing our effort on dealing with light bulb botnets
> than trying to get people to make secure "smart" light bulbs. There is no
> good solution on our end, and debating the price of chips for light bulbs
> is not a good way to make security decisions in TLS.
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>