Re: [TLS] [Cfrg] 3DES diediedie

Jon Callas <> Mon, 29 August 2016 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5420312B056 for <>; Mon, 29 Aug 2016 14:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eKL7OzxvF0s for <>; Mon, 29 Aug 2016 14:46:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B9324126FDC for <>; Mon, 29 Aug 2016 14:46:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F749A14A691; Mon, 29 Aug 2016 14:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MFIXoK-9-9sP; Mon, 29 Aug 2016 14:46:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id E2253A14A681; Mon, 29 Aug 2016 14:46:49 -0700 (PDT)
Received: from [] ([]) by (PGP Universal service); Mon, 29 Aug 2016 14:46:49 -0700
X-PGP-Universal: processed; by on Mon, 29 Aug 2016 14:46:49 -0700
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jon Callas <>
In-Reply-To: <>
Date: Mon, 29 Aug 2016 14:46:47 -0700
Message-Id: <>
References: <> <> <> <> <> <>
To: "David McGrew (mcgrew)" <>
X-Mailer: Apple Mail (2.3124)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Jon Callas <>, "<>" <>
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: Mon, 29 Aug 2016 21:46:52 -0000

> 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

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.