Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" <> Tue, 30 August 2016 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A03112B063; Mon, 29 Aug 2016 18:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p-6cfQQRXZel; Mon, 29 Aug 2016 18:21:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14F7D12B05E; Mon, 29 Aug 2016 18:21:51 -0700 (PDT)
Received: from hazelnut ( []) by (8.13.8/8.13.8) with ESMTP id u7U1K42x015563; Mon, 29 Aug 2016 21:21:40 -0400
Received: from hazelnut (localhost.localdomain []) by hazelnut (Postfix) with ESMTP id 46E1C6D; Mon, 29 Aug 2016 21:21:40 -0400 (EDT)
Received: from ( []) by hazelnut (Postfix) with ESMTP id 254BE6D; Mon, 29 Aug 2016 21:21:40 -0400 (EDT)
Received: from [] ( []) (user=smb2132 mech=PLAIN bits=0) by (8.14.4/8.14.4) with ESMTP id u7U1LdYW018785 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Aug 2016 21:21:39 -0400
From: "Steven M. Bellovin" <>
To: "Jon Callas" <>
Date: Mon, 29 Aug 2016 21:21:38 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (2.0BETAr6052)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.78 on
Archived-At: <>
Cc: David 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: Tue, 30 Aug 2016 01:21:53 -0000

On 29 Aug 2016, at 17:46, Jon Callas wrote:

>> On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) <> 
>> wrote:
>> Hi Peter,
>> You make a bunch of good points.   But it is also worth noting that 
>> some people feel that current crypto standards, including IETF 
>> standards, are suitable for IoT.   See for instance slides 8 and 9 of 
>> Daniel Shumow's talk at NIST’s LWC workshop last year: 
>>   Also, CoAP isn’t on his list, but it could be, and it uses DTLS.  
>>  So while I agree with you that overuse of a 64-bit block cipher is 
>> far from the biggest security concern for IoT, the IETF should expect 
>> its protocols to be used in some IoT scenarios.
>> The malleability of the term IoT is causing trouble here.   Slide 6 
>> of Daniel’s talk is quite revealing.  To my thinking, by definition 
>> IoT devices are connected to the Internet in some way.
> Definitely. But to quote Shumow's talk on Slide 10 (which has the 
> title "IoT Does Not Need Its Own Crypto Standards"):
> • Current cryptographic standards work for IoT
> 	• Current standards are not a limit on IoT performance.
> 	• Perspective: Common IoT platforms are approximately as
> 	  powerful as PCs from 15 years ago when AES was standardized.
> And on Slide 11:
> • Adding new standards can be problematic:
> 	• New standards, especially with lower key sizes could be
> 	  used in scenarios where they aren’t intended.
> 	Example: Standardizing ECC over 160bit prime for an RFID
> 	  card and it ends up being used for https; block cipher
> 	  with 80bit key space ends up being used to encrypt hard
> 	  drives.
> His conclusion (slide 13) says that we don't need Lightweight Crypto 
> in software, but admits there are some hardware places (like RFID) for 
> it.
> And that gets to Peter's basic, good points. While Peter is being 
> brash, his larger point is the same point as Shumow's, that we should 
> just be using our existing toolbox and that even *that* has too many 
> choices. The AllJoyn suite, which is the most stripped down, is 
> brilliantly simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can 
> quibble with it, but it's to the point. (My quibbles would be to toss 
> RSA and Curve 41417 instead because it has an ARM NEON implementation 
> that's as fast as P-160. But those are quibbles.)
> Folding back up to the subject here -- AES is faster than DES. That is 
> one of the reasons it was selected as AES. (So are Twofish and 
> Serpent.) We need to toss all 64-bit block ciphers. They were okay way 
> back in the 1900s. It is no longer then. AES is cheap and getting 
> cheaper. We don't need to patch up any of those old ciphers with 
> meshing or what. We just need to use what's in our toolbox. 3DES needs 
> to go solely because it's a patch on DES that needs to be patched for 
> its small block size. I know it's boring to just use AES, but it meets 
> all the goals.

Yes.  To a large extent, the "IoT devices are too puny for real crypto" 
is a hangover from several years ago. It was once true; for the most 
part, it isn't today, but people haven't flushed their cache from the 
old received wisdom.

It pays to look again at David Wagner's slides from 2005, on sensor nets 
and crypto:

         --Steve Bellovin,