> On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) <[email protected]> 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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
