Re: [Cfrg] [TLS] 3DES diediedie

Kyle Rose <> Thu, 08 September 2016 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1E1912B32E for <>; Thu, 8 Sep 2016 09:11:27 -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 c-KiFflAc5PI for <>; Thu, 8 Sep 2016 09:11:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C61C12B3AB for <>; Thu, 8 Sep 2016 09:08:16 -0700 (PDT)
Received: by with SMTP id z190so37811254qkc.3 for <>; Thu, 08 Sep 2016 09:08:16 -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=Qajvo5YMiGQj7QCeO6kRF8eE+ZNGcDalwlELklEGNME=; b=CYQXHzC4+6Z/FHFTYroDxbObmhYP2JYHmopQJgo9voihk1V6YF2IB1IZe17EyIvIX5 x7lyreikN2p6SIJRLt7ucNCpOcKHuc9wQKvCNDLYlqfzcfkYtBjWzsIdFh+nPmoxREE8 DuQ95TR4zI2JBM0s4a6IorPcPy2SOqrt6GrR8=
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=Qajvo5YMiGQj7QCeO6kRF8eE+ZNGcDalwlELklEGNME=; b=JrivQZ3PPlE2mzPEegOODV+8eJ7e+QBfY3gWMukctgHDriCG1maGwMSLCTXT4C0kRr AOdm5pWB42iQ6QmZ0x+VShEgEUtrne6TAi1jEYeajTvirCcuJIF2oUUh9vHzhkp2eHdq HRW1PP04dj79StC2N1G8SaixKfC9G79mMecReCn3RqsHUvDZHWnvapLccb/qbZ2SxFYA YOelOv/jJU9sjYIphAG+30zcfjL0GW9Zp8OrBv/dIBB2pLtkRgyScY0RfUQ4niAdULIs QNBoxnkDR/A1Y+3BnpTIMOVqUeHLLJwerqXBteqaCzbkhMT8/cpJ+v+VFe21NZIOoLGg 3/fQ==
X-Gm-Message-State: AE9vXwPbb/F5CouXEyjJYnYkM4+Kvxk7JgRWtR+L9MTAnzwJQx4k8TUkhg296oCnubD+WAooMPadps+53Nd+VA==
X-Received: by with SMTP id z125mr567510qka.184.1473350895365; Thu, 08 Sep 2016 09:08:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 8 Sep 2016 09:08:13 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Thu, 8 Sep 2016 12:08:13 -0400
Message-ID: <>
To: Peter Gutmann <>
Content-Type: multipart/alternative; boundary=001a114a8c86bf8867053c013cc0
Archived-At: <>
Cc: "" <>, "" <>, Richard Hartmann <>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 16:11:28 -0000

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann <>

> The only data point I have is that every time I've tried to disable DES in
> a new release (and by DES I mean single DES, not 3DES) I've had a chorus of
> complaints about it vanishing.


>  Alarms, for example, send data
> quantities measured in bytes, so some academic attack that would take 500
> million years to acquire the necessary data isn't going to lose anyone any
> sleep.  It's a nice piece of work, but you need to look at what practical
> effect it has on real, deployed systems...

To this class of examples, the problem seems to be less the implications
for security of the specific systems making use of weak crypto, and more
the effect the survival of weak options for crypto might have on other
systems. We don't want more general systems to be subject to attacks that
may not be applicable to the resource-constrained target systems, but that
requires us to answer a few questions about those constrained systems:

(1) Is the target system isolated, such that a compromise cannot either
leverage transitive trust to another system or provide an attacker a beach
head from which to attack (surreptitiously probe, etc.) other systems?

(2) Is the weak crypto being used by the target system in a way that
renders both the known and expected attacks inapplicable?

If we can answer #1 "yes", then all a user is dealing with is a device that
might malfunction in a well-defined/delineable way upon compromise, with no
impact on other systems. It might be hard to definitively answer because,
for instance, a light bulb malfunctioning might create a safety incident if
the light bulb is a control panel indicator for some problem, so I don't
want to minimize the difficulty of coming to a "yes" answer here.

If the answer to #1 is "no" or is too difficult to answer, however, then we
have to actually analyze the weaknesses in the crypto with respect to how
the device could be used.

Where I'm going with this is that #1 is going to be particularly difficult
to answer if the protocol making use of the weak crypto is TLS and the
device is connected to the internet, simply because the potential for
complex interactions is so high. The safest course may be to continue to
deprecate weak crypto for TLS, IPsec, etc. under the assumption that the
systems making use of those protocols are both powerful enough and
well-connected enough to cause a problem if compromised. Nothing stops
resource-constrained systems from continuing to use old implementations of
TLS that do support weak crypto, though I question the wisdom of producing
parts with no upgrade path that speak such a complex, general transport
protocol rather than something naturally 0-RTT in the steady state that
would use less CPU and power, have a smaller TCB, and not rely on an ASN.1
implementation for domain isolation (e.g., Kerberos).

Which leads directly into the issue of the potential for implementation
vulnerabilities, something that is probably even more likely to lead to
loss of control than weak crypto, and which may ultimately force users to
demand IoT devices for which the answer to #1 is always "yes". So I wonder
if all the worrying about weak crypto is just a red herring compared with
the exploits we are actually going to encounter.