Re: [TLS] [Cfrg] 3DES diediedie

Karthikeyan Bhargavan <> Sat, 27 August 2016 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36C8F12B008 for <>; Sat, 27 Aug 2016 09:36:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oMP0PKV3ChcV for <>; Sat, 27 Aug 2016 09:36:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A84512B014 for <>; Sat, 27 Aug 2016 09:36:02 -0700 (PDT)
Received: by with SMTP id z190so103926822qkc.0 for <>; Sat, 27 Aug 2016 09:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNoMXmKYkIczqbrXF3X8I4spaZqofIFOgM/GsJ91eyU=; b=fXJhGT7pm9AS89n6pOjML7KZLivUCbRftLJTxpv2+pibpc5VwR+cTWOE/MdjkQYNV1 HeHIrof/AASRbmTaBDxdhd4mE4TI2JXLSgpfD44/y4VPqPP5iUTfK2GY5QVQBKDDm3br YnEdSUgpCujKsgrVbMFqAryFukFkN8tIZIgQrAUaE7oYTkhsISmm+a+9Nuq7HoTYrWCt wZJNAjT8yMJPTkHbeCbAAFuIia8Lm0Z1MBwvd0H8DVTuqDOc72HaSZwEJ/p5uTVB1BZE /tL3Wf0PaSz0oA2Zzhc8BliEeL3LfILt+Cjd+7z71BH6hEUEK6ngQW54+85EAsvFPfq+ jO/w==
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 :content-transfer-encoding:message-id:references:to; bh=gNoMXmKYkIczqbrXF3X8I4spaZqofIFOgM/GsJ91eyU=; b=MTi/MrZ6HlkPJV/OTNAd7JV+HENVHHyqaxW83hCbnSWri1kMNkTNNA27xrh8Tv1DSd weOHBmqZ+7WzeK3REVPKpf+0bdwbeXvc8Md3P8CwO6AzjdRevxDIXAGTAKcf9PKzdVUZ 9SDWfqOtmZ36rOq+rKhWqoO18zWNPiTC8ijOCWxLBcnUEckwztIfrjfx10IZuEepB25p 6h+nabgRQnVj3ZlsYMvOvfWDKxUSxyRCLbLAu4iKhU2h3ugREsFDJUxdPbXo+4PC78vp 57U3jKWZa+hLW22e1TS+L4i5n6kbDViHud8G4ZcCQ+hCyi/jAqXcxat12Vf/IJb2Kt1d FTeQ==
X-Gm-Message-State: AE9vXwNPPb+/OvPBRdvbGqHL9frLuWa7jzvTXdmPpAqm65IsptuThynZEGOcGBilpwuCzg==
X-Received: by with SMTP id g8mr8768615qkb.33.1472315761549; Sat, 27 Aug 2016 09:36:01 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y36sm13399423qtc.46.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 27 Aug 2016 09:36:00 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sat, 27 Aug 2016 12:35:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "David McGrew \(mcgrew\)" <>, "" <>, "<>" <>
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: Sat, 27 Aug 2016 16:36:04 -0000

> Looking at it from the other side, your typical IoT device will be sending,
> for example, a 12-byte message every 15 minutes, meaning it'll take, if my
> calculations are right, just under two million years to collect the 785GB of
> data required to perform the attack.

I agree that it would be wise to evaluate each deployment scenario to decide
which vulnerabilities have higher priority. But just a brief comment.

If every message IoT device sends is a 16 bytes message consisting of one 8 byte secret and one 8 byte known plaintext,
then with a 64-bit cipher, we only need roughly 64GB in order to get a meaningful collision (50% chance of recovering the secret).
The 768GB value we gave was for recovering cookies from realistic web browser traffic that could be triggered from JavaScript.

It is true that in other TLS use cases (such as IoT) some attacks may no longer be relevant, but unless we are careful
some HTTPS attacks may even be worse in these scenarios.

Best regards,

> So you've got something where the devices aren't vulnerable to the problem
> (and nor, in any practical case, is anything else), for which the devs
> involved won't even know that any guidance on the situation exists, and for
> which, if anyone really wants to attack them, they can use any of the dozens
> of insecure-by-design holes that are present in the device to own the whole
> thing, at which point what you do with your crypto becomes meaningless.
> So what you're proposing is essentially a non-solution to a non-problem...
> still, if you feel like writing the memo for it, don't let me stand in your
> way.
> Peter.
> _______________________________________________
> TLS mailing list