Re: [TLS] [Cfrg] 3DES diediedie

[Jon Callas <[e-mail]>]

> On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) <[e-mail]> 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: http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf   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.

	Jon