Re: [TLS] [Cfrg] 3DES diediedie

Kyle Rose <> Thu, 08 September 2016 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3882A128E19 for <>; Thu, 8 Sep 2016 10:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zG2LPMyoF6id for <>; Thu, 8 Sep 2016 10:36:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C470512B01E for <>; Thu, 8 Sep 2016 10:36:58 -0700 (PDT)
Received: by with SMTP id w204so52167838qka.0 for <>; Thu, 08 Sep 2016 10:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sfiRqwLuGEqGodg5QCr4Z6GLOe4pmAFRVSNVxlf1q/0=; b=gz1XDFGKROyprk7dnjUXBpvn7We8VcO+ckcrsJvT4ZLAKATIG3kcIGhf15kQRVxgAl dza8Tz+LFGlJI9rhQe7RqSFHX9SjpfZBdfLmzgjRKxR2xskS2bC9jnUuvowSD3o536E0 V9Twv7CMpxATnDBANXSqY4vqqEFglL+XadyV3T/tHLpVKvHsmGDMXnm0i4m19/9nsIx7 64WlVQBpE0MjWyuNUW+Elaa9CnDRsEf4SN4B5HguJlv845pYMTFA4oTXS5Beiz9tHxjB HegOpC7N8IFO2HtzPrPKIQsRD3hDEUjwSq9O0Tmvr8x2v0XH9Q6gOTyUeLgU4MNJcQs1 XtAw==
X-Gm-Message-State: AE9vXwNmJPSd8tL/4EhfLtEafHd3P1s7Uwx/OMfAh+XaWSdzbcq1NeborMdOEeoa+tzYshKpvVzrQ9TrETO1LA==
X-Received: by with SMTP id l129mr1131217qkb.0.1473356217859; Thu, 08 Sep 2016 10:36:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 8 Sep 2016 10:36:56 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Thu, 8 Sep 2016 13:36:57 -0400
Message-ID: <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary=001a114f1b34fe6d7f053c0279a6
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 17:37:02 -0000

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir <> 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

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.