Re: [Cfrg] [TLS] 3DES diediedie

Tony Arcieri <bascule@gmail.com> Wed, 07 September 2016 02:16 UTC

Return-Path: <bascule@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 E5F8A12B47F for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 19:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 y14tI-sbLDGK for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 19:16:34 -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 A486512B0F8 for <cfrg@irtf.org>; Tue, 6 Sep 2016 19:16:34 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id j189so1612506vkc.2 for <cfrg@irtf.org>; Tue, 06 Sep 2016 19:16: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=ZaTmyN9gRL0EaHIxfezcavysZLRrmAfepAl2qvXzhfA=; b=iU44PubhWGbvJWy2xUUVWrEQbN85h/UTxFQNE1i06+S4If/rtKqXIyZE4TnSa7Dqpt X0bWCMVnIGQFjxoMhryy1vJ+HDR+OlvJ7SDxxvTzJOv/WpIKEaHrboJJY/IsWuJPLNMl 0WsQ/WRopcy3HKVUZ2gtt5c4DONEqM5iCEozJropbBx/xixmNMkK6EUQMBSLZJ886ThI 2X/Y9BnK2oARDSpGnQfOZnzdvDq3K8B31RoHvvN2SjjIViaZVD4nau41k59jbIh8QqHQ qUhFiu9uVc2uz9dfwV4IxmQNTLVLmbdaJvMNsGmp00QiGXpiK8NX//+IAeLTL5MA2eoW 8bXA==
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=ZaTmyN9gRL0EaHIxfezcavysZLRrmAfepAl2qvXzhfA=; b=Q38aIVy3UTs5sw5ZJYyc8rYPykuvzwFf5NPpEnxBTj0E0b1V5L5Mw5b3ZJcTG/eDyi RIOlpq45LKACEQqLZlvTERzTLZCo0LGz2MHAra95w5ohjbAbvJrYhuQMAs7KvoAcd2eT 5YUZKlzPUr5eyTSMo9p1idTBSRcStzMcy65faAmHd8mQcBp/IyaSsExUfqQqgrMymMih BiFcaJcKkyW/bDVDnrQ+OTwc6MGzEaErOIQDWX3lRAt7RNxk6+HlPjkEFPBhr9WdIjb0 3WCgwBo2ZIfkpWxVsBsfXoXriWuEk6ECy2hIz48efuM7hGDzEOD7Y37j8SpfHbf4TZB2 DNmA==
X-Gm-Message-State: AE9vXwPqBhZmiTx4U0Jbkox0VeaoUAl7vC/ky3ZyCmk/WGyxZWKJieGjxnbiEbMn5S0puJvxgJd6tnohAPgWmA==
X-Received: by 10.31.136.70 with SMTP id k67mr27281876vkd.13.1473214593725; Tue, 06 Sep 2016 19:16:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.79.90 with HTTP; Tue, 6 Sep 2016 19:16:12 -0700 (PDT)
In-Reply-To: <CAN40gSv3dOENg_fh-4OFgJ72UFNNX9rr=v2HtoiNaLDMwh21NA@mail.gmail.com>
References: <20160906114030.18292816.41703.89024@ll.mit.edu> <57CEAE6F.1040608@secworks.se> <sjmeg4wvjut.fsf@securerf.ihtfp.org> <d1b84ec2-5b02-b285-8304-e3b393d9ee4a@cs.tcd.ie> <CAN40gSv3dOENg_fh-4OFgJ72UFNNX9rr=v2HtoiNaLDMwh21NA@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 06 Sep 2016 19:16:12 -0700
Message-ID: <CAHOTMV+UO7BqqruhhHRtiaBLRFh=zC-vQ6BhM7xZNZRC2bpDAg@mail.gmail.com>
To: Ira McDonald <blueroofmusic@gmail.com>
Content-Type: multipart/alternative; boundary="001a11440bb6897e98053be1801d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rzKk-Okua_zSZtzSjPVSG3aR7m8>
Cc: Hilarie Orman <hilarie@purplestreak.com>, "cfrg@irtf.org" <cfrg@irtf.org>, Joachim Strömbergson <joachim@secworks.se>
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 02:16:37 -0000

On Tue, Sep 6, 2016 at 4:36 PM, Ira McDonald <blueroofmusic@gmail.com>
wrote:

> But I wanted to observe that, after my recent years working in the
> auto security area, there are extreme cost constraints (and power
> constraints) on CPUs in small sensors and smaller auto ECUs.
>
> Cents matter.  Dollars are out-of-the-question.
>

There is definitely a middle ground here: there are 8-bit "secure MCUs"
with crypto accelerators.

Another factor to consider is how severely these devices have previously
failed from a security perspective: attackers pivoting from wireless tire
pressure sensors have been able to move laterally to ECUs, and at that
point are able to do any number of things that could cause a vehicle to
crash:

http://www.winlab.rutgers.edu/~Gruteser/papers/xu_tpms10.pdf

In every other space besides IoT hardware crypto accelerators are the norm.
They have certainly been the norm for the payments industry for decades,
but that's an industry that has much more experience with the risks,
whereas the "Internet of Cars" is relatively new.

I think the automotive industry needs to come to terms with with the fact
that it may need a "security budget", because there are definitely huge
risks that need to be addressed.

One could argue "well then they won't use TLS", which may be true,
> but's it's a dangerous path IMHO.
>

Equally dangerous is deploying TLS insecurely. As an example of what I
consider necessary for security: are they capable of receiving fully
automated security updates? There have been a litany of TLS
vulnerabilities, especially recently, and unless these devices are capable
of these updates they will effectively be "insecure forever". In such a
case people may write off security concerns as "it's protected by TLS", but
they may be vulnerable to a Heartbleed-like attack, or perhaps they're
validating certificates incorrectly ala
https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf. These vulnerabilities
need to get fixed, or TLS is worthless.

I expect the answer to the "can these devices perform automated software
updates?" to be a resounding no. But if people really want to deploy TLS
successfully and securely for these use cases, that answer needs to change.

Is your 8-bit MCU with no crypto accelerator really up to the challenge?

-- 
Tony Arcieri