Re: [TLS] [Cfrg] 3DES diediedie

"David McGrew (mcgrew)" <> Fri, 26 August 2016 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0962E12D507 for <>; Fri, 26 Aug 2016 10:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Status: No, score=-15.068 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6w3f4jgfgpyJ for <>; Fri, 26 Aug 2016 10:55:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1526D12D504 for <>; Fri, 26 Aug 2016 10:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8926; q=dns/txt; s=iport; t=1472234119; x=1473443719; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rXWPx3FJglC3HbHfn01Qr3K2GiDyghvrxQX2L6VSM7c=; b=MlekeNSZKPHJqrBczmb6GmDCMicHlhExehVEOotqQaUT8lt9Zz4/wVLQ 4IOFfpGlviv7HxiX9dLHhKXbNET5Iajb9vdBykvqG4F4rDxOH/K8k6ykn RrXRkA4F6xfZuR/kjGWc4YpQFMxaIJyoE7ALB/4+2ZjqDba03cjrXt2T1 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5EAChgcBX/49dJa1dgw4zAQEBAQEeV?= =?us-ascii?q?nwHhCSnS4cnhQmCASCFfQIcgTI6EgECAQEBAQEBAV4nhGEBAQMCI2YCAQgOAwM?= =?us-ascii?q?BAigDAgICHxEUCQgCBAESiB4DFw6wIYteDYNOAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYgmCIJNghAzgh2CYiuCLwWTcIUoNAGGH4Y+gkuKeoRYiDqECYN4ASUCLYQ?= =?us-ascii?q?ccAGFTH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,581,1464652800"; d="scan'208,217";a="142102898"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2016 17:55:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7QHtJ0S019328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 17:55:19 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 Aug 2016 12:55:18 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 26 Aug 2016 12:55:18 -0500
From: "David McGrew (mcgrew)" <>
To: Tony Arcieri <>, "<>" <>, "" <>
Thread-Topic: [Cfrg] 3DES diediedie
Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgA
Date: Fri, 26 Aug 2016 17:55:18 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F42128A0968240428C7EE3686743B314ciscocom_"
MIME-Version: 1.0
Archived-At: <>
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: Fri, 26 Aug 2016 17:55:22 -0000

Hi Tony,

Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES would be a good thing.  The only good reason to use it is backwards compatibility, and too many applications don’t heed the birthday bound.

There is another issue to be considered, though.   Most of the lightweight “designed for IoT” block ciphers have a 64 bit block size (and sometimes even smaller); see for instance Table 1.1 of     So perhaps what the Internet needs here is sound guidance on how to use 64-bit block ciphers.   Best practices here include both mandatory rekeying well below the birthday bound and/or the use of secure beyond the birthday bound modes of operation such as Iwata’s CENC.



From: Cfrg <<>> on behalf of Tony Arcieri <<>>
Date: Wednesday, August 24, 2016 at 10:08 PM
To: "<>" <<>>, "<>" <<>>
Subject: [Cfrg] 3DES diediedie

This attack was published today[*]:

I bring it up because I think the threat model is similar to the threats that lead to RC4 "diediedie"

Should there be a 3DES "diediedie"?

I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense for it to be banned from TLS 1.3.

[*] Lest anyone claim the contrary, I am not surprised by this attack, and have pushed to have 3DES removed from TLS prior to the publication of this attack, and can probably find a TLS implementer who can back me up on that.

Tony Arcieri