Re: [TLS] [Cfrg] 3DES diediedie

Yoav Nir <> Thu, 08 September 2016 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F63012B1CF for <>; Thu, 8 Sep 2016 09:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eDDGpaHikApV for <>; Thu, 8 Sep 2016 09:46:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2C1C12B0D2 for <>; Thu, 8 Sep 2016 09:46:06 -0700 (PDT)
Received: by with SMTP id w12so100195219wmf.0 for <>; Thu, 08 Sep 2016 09:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iWHzgARyqj1Ty+oqjmg1VkdN85eqJDTLqsTmZwrZdXk=; b=ji4ZpcS5QBHYx2d0x1d+G1GvZns45uXM7lXpHKVUzFAzqq9kCDvq7gy0xylY4jtiuV hziRIt6I7oKEJMg/vFJNlVdY7RaMxkopRxW1yNukdvVQO3VlCfMdfX16rfHXRI32pB3v c4q1hGOxWM2kDsFWc5CRtADvprPnuin+VpZ664ExvO192x2jLotcwaJankkQtDDICkPt zEMQPTtPZfnKDKRIWbyKKODxKXj0CxH5JR7ynv01mTKVn7QWBGZpLOvQiqf6CWrGX2Yb FCTxhHlD10DTmnkt12AwHmpLV9dTPLZnqnyKKCT6vFXx9SZzr32PaiQYeoL8a+bY2mAS ocTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iWHzgARyqj1Ty+oqjmg1VkdN85eqJDTLqsTmZwrZdXk=; b=B8SL3TyW1VRSaV+kSCmXKCMDDKI4V4JOQQnztYnePvf/P/131WjRoFOHkVlUD0/qn6 aOr2rxkpNndL03Hz7/+g368wEF2XZasmBty1RVGFmt/P755t790lXqLhx8bqLCQ3NoZQ rzBruswJB3Di9z+LWSsuDBb+URwk13XEpuro8xWu5YAG00CZNLWRLeVueLm/RoMR35Xf C2DsGQXHgt3gCyZMq5V+Wu3/qQZuTgWviDc4Np93w+H+QfbgNyhDwiFOQTrH7QgfWvQh Ewwk8eVufbFhPZtUy1zYSqhQArdFaovZkSnHn+ewR9BtRva3hAJ1fdWQ2DR/h3dz0+V4 ntCA==
X-Gm-Message-State: AE9vXwPHOHO7m+BIbIf8o9n/HOs6bHu+vqY40Ocfi5rcDXMW8SUpOMObkW5mrWDpkLkeFQ==
X-Received: by with SMTP id bo1mr525268wjb.105.1473353165099; Thu, 08 Sep 2016 09:46:05 -0700 (PDT)
Received: from ([]) by with ESMTPSA id 17sm10568205wmf.6.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Sep 2016 09:46:04 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A70BBB31-C6AF-4EE9-98FC-BE3CDE0AB57D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 8 Sep 2016 19:46:00 +0300
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Kyle Rose <>
X-Mailer: Apple Mail (2.3124)
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 16:46:09 -0000

> On 8 Sep 2016, at 7:08 PM, Kyle Rose <> wrote:
> On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann < <>> 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?

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. We as an SDO are 7 steps removed from this, so we can’t make that determination. We can be sure that if we specify a protocol that will prove successful (as in adopted) by industry, that protocol will protect lightbulbs, but it will also end up protecting critical infrastructure, high-value targets and probably even lives.

We can’t even make Peter’s assumption that these things send only a few bytes of data, because many things send very little data. But some things will send a lot of data. And putting “no more than 1 MB per day” in the security considerations section is an exercise in futility.