Re: [Cfrg] [TLS] 3DES diediedie

Kyle Rose <krose@krose.org> Thu, 08 September 2016 17:37 UTC

Return-Path: <krose@krose.org>
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 B5C2F12B03F for <cfrg@ietfa.amsl.com>; Thu, 8 Sep 2016 10:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 5GXe8vz4Ce2l for <cfrg@ietfa.amsl.com>; Thu, 8 Sep 2016 10:36:59 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 C457E128E19 for <cfrg@irtf.org>; Thu, 8 Sep 2016 10:36:58 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id m184so50084443qkb.1 for <cfrg@irtf.org>; Thu, 08 Sep 2016 10:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sfiRqwLuGEqGodg5QCr4Z6GLOe4pmAFRVSNVxlf1q/0=; b=TKWSqtTeu165Gp+k3b2DXCzsHgiHqrqKW78g5RDtyAtibxiuGO03JEGK0RD/3tEjGG WkOBk0cQqGsmuZt0E7382lSIJ63KuI58z0roY4mM5xNrH/Ijv0Oq1LOYZ7usFG3yOtme 3dPfSwXboCPyf6eHYEqnfFg2iXZXpKW6y91cY=
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=sfiRqwLuGEqGodg5QCr4Z6GLOe4pmAFRVSNVxlf1q/0=; b=SmlBqUP8B8iooCjMvcAgMnJv41DOGzSHTnjoL1L2LALxI0hh3eUmAg73k1jHvOUR+P 9Fqk9ioKmrISROkoVhFTj/EUl5+Uzl4ErJSe/Xld3Bvu+YRM6xt0+G7IqGSZrofNFDiO SqmVm4HKS57JziwptQ3P1MWVP5JuDhoDbQRi0gZqHKHj+TrbhxdUEkvbZrdJCdRCJoEf ab0CpK7pHSJdLzEnKQNhXtma+q1fLVKPB+sHFM2Q2MZVHyjBkypiKiC7XzBEzMnLyDh7 ORtia+cw1gOcbDfGJ3dQtFDg+W4RmAPAbMr8URAN74ssVQucAAIOnGQYWJVsRXuixssi ExmA==
X-Gm-Message-State: AE9vXwPImoduyM4rrENPvfkqaAvXUH+zTf3NPHaOeT7MKeYvUoCooVq3eexEmWLJL15Ead/DWu5X+1UhQSW5Jw==
X-Received: by 10.55.87.135 with SMTP id l129mr1131217qkb.0.1473356217859; Thu, 08 Sep 2016 10:36:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.130.197 with HTTP; Thu, 8 Sep 2016 10:36:56 -0700 (PDT)
X-Originating-IP: [12.206.21.98]
In-Reply-To: <7A47F474-83F6-4296-863B-6CF8A87C616A@gmail.com>
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> <CAD77+gSWkttd1_r75GFvZgWotqMZtH0ry5Qw62n-jZkU8mJQGA@mail.gmail.com> <1473314009688.88774@cs.auckland.ac.nz> <CAJU8_nVZSEwAyJC1KL_jOg77DzOkeQv6T5UBKFnn8DUgAUaM0w@mail.gmail.com> <7A47F474-83F6-4296-863B-6CF8A87C616A@gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Thu, 08 Sep 2016 13:36:57 -0400
Message-ID: <CAJU8_nXEJrqBPB1OLKieyLkCm+AAGdHti2hPp3TPE_t9BDntMw@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a114f1b34fe6d7f053c0279a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/8YRz4MGe-meqyHpv5KPrsNM7UuE>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
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: Thu, 08 Sep 2016 17:37:02 -0000

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

>
> Good questions, no doubt. But I don’t think they can be answered.
>
> Someone is going to specify protocols and algorithms. This could be the
> IETF. This could be the ITU, or IEEE, or some other SDO. Makes no
> difference.
> Someone is going to implement these protocols and algorithms in some
> combination of hardware and software.
> Someone is going to combine this implementation with other parts like
> network stack, wired or wireless communications, memory to create a
> “brains” for IoT devices.
> Someone is going to build a sensor or an actuator that includes that
> “brains” plus hardware and software. This could be a lightbulb, and smoke
> detector, a temperature sensor.
> Someone is going to use this sensor or actuator as part of a system: a
> car, a refrigerator, an HVAC system, a door alarm.
> Someone is going to deploy these systems in a home, in a data center, in a
> plane, in a nuclear power plant.
>
> It’s that last step that determines how attractive this is going to be to
> attackers and what value is going to be protected by a device using these
> protocols and algorithms. And the last two steps determine how isolated the
> “thing” will be.
>

Not necessarily. Manufacturers may be able to push some of those isolation
properties higher into the list. E.g., if the silicon simply cannot speak a
more general protocol even if compromised, or has some other physical
constraint (e.g., data rate, CPU power, etc.) that limits its
expressiveness, you may be able to make provable statements about the
potential impact of compromise. We obviously can't impose those
restrictions on manufacturers, but I don't know if it's completely hopeless
to create standards or compile best practices for mitigating compromise of
insecure devices.

But this brings me back to my earlier post where I said this sounds like a
research problem: the IETF is not anywhere near being in the position of
making such recommendations. And I'm not convinced that this path is a
productive use of our time, when hardware being hardware means that
increased functionality (better crypto, upgradability) gets cheaper all the
time.

OTOH, manufacturers being manufacturers means that security and
upgradability are baked in only when users demand it, and users being users
means that no one demands either until it's too late. So it's possible
there's real value in doing the research and then creating safety standards
for classes of devices that seem to be designed to atrophy, but it's
probably more useful for that standardization to focus on network isolation
rather than on crypto since the crypto is only one small part of the TCB.

Is the era in which the marginal cost of upgradability is too expensive to
support a short one, or is this a problem we're going to be dealing with
for a long time? If the latter, then I'm starting to see some value in not
having everything be globally-routable or even talk IP.

Kyle