Re: [TLS] [Cfrg] 3DES diediedie

Kyle Rose <krose@krose.org> Thu, 08 September 2016 16:11 UTC

Return-Path: <krose@krose.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9555112B32E for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 09:11:26 -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 kyMXGU3qxNrL for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 09:11:23 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 4C66112B47F for <tls@ietf.org>; Thu, 8 Sep 2016 09:08:16 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id w204so49356518qka.0 for <tls@ietf.org>; Thu, 08 Sep 2016 09:08:16 -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=Qajvo5YMiGQj7QCeO6kRF8eE+ZNGcDalwlELklEGNME=; b=CYQXHzC4+6Z/FHFTYroDxbObmhYP2JYHmopQJgo9voihk1V6YF2IB1IZe17EyIvIX5 x7lyreikN2p6SIJRLt7ucNCpOcKHuc9wQKvCNDLYlqfzcfkYtBjWzsIdFh+nPmoxREE8 DuQ95TR4zI2JBM0s4a6IorPcPy2SOqrt6GrR8=
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=Qajvo5YMiGQj7QCeO6kRF8eE+ZNGcDalwlELklEGNME=; b=Ucn2A3aMQx90/CHxcQ7S39c6nQip7VFtnnO0FthinY8SlqyuvDtSzCTkR5Ne1D1hvA 8dUncJnPXZcN1nFNmPUogwCHPpaJXZFY9Yxf2sfwZwU/I7Vf8MmKe0lM4n2dTMvugJ9U rBYw/lsga9hRJFIUEW+ZyUUPOR0YBfpm0MByuNedVz1/gayeY78jy7fNJamdonOusCD0 XYsSB6y8oreFLy+COt3EpYvk/Gw6NUqV3C3mCYQbnreSReB7LT4A13YRJIp1HjGyUIu2 Pjf274+qjQ/f7XzU7nDM4NoYh7SVE82KUTVCesFzAzE+rDdq9j5+dpvpudQaw0gjISWt ratg==
X-Gm-Message-State: AE9vXwPq8MTj4jRo8NSQDTqJMDSLEZttSmrRpxw798jwgFqAhm7GsurlsxUHE4Huxzl5H6haPGkx7s2AHjDOSQ==
X-Received: by 10.55.76.131 with SMTP id z125mr567510qka.184.1473350895365; Thu, 08 Sep 2016 09:08:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.130.197 with HTTP; Thu, 8 Sep 2016 09:08:13 -0700 (PDT)
X-Originating-IP: [12.206.21.98]
In-Reply-To: <1473314009688.88774@cs.auckland.ac.nz>
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>
From: Kyle Rose <krose@krose.org>
Date: Thu, 8 Sep 2016 12:08:13 -0400
Message-ID: <CAJU8_nVZSEwAyJC1KL_jOg77DzOkeQv6T5UBKFnn8DUgAUaM0w@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=001a114a8c86bf8867053c013cc0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/N6UkHAU1IQW1Ea2sq_Hq6JgP0EE>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 16:11:26 -0000

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>;
wrote:

> 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.

Kyle