[iot-wg] algorithm agility for IoT

Jim Reid <jim at rfc1035.com> wrote:
    > I’m working on a document at ITU Study Group 20 on algorithm
    > agility. [So you don’t have to! :-)] The aim is to produce a
    > Recommendation which essentially says “don’t hard-wire crypto
    > algorithms into IoT stuff because what’s secure today could be insecure
    > tomorrow”. For instance, building or deploying an IoT solution that
    > can’t use anything but MD5 or DES (say) would be bad. Similarly, it
    > would be undesirable to install a sensor network today that can’t
    > handle tomorrow's devices because they might well use new crypto which
    > isn’t around today.

In general the current IoT "MUST" seems to be ECDHE-ECDSA-AES128-CCM8.
(This is an AEAD, so AES128 is also the integrity protection)
It has a slightly different name in TLS 1.3.  Having only one for a small
device is not unreasonable from a hardware point of view, but from a systemic
point of view, it causes a flag day.
A can not upgrade because B does not support it, so A does not add anything
new and when B decides to upgrade, A does not support anything new.

It appears that hardware that supports AES128-CCM8 also supports AES256-CCM8.
That's a bit of an upgrade, but the only thing wrong with AES128 is that it's
considered too small for the first Quantum attacks.  Somehow AES256 is
considered big enough to withstand things. (Don't ask me...)
But if a Quantum Computer can break AES128, then it probably will have
already broken ECDSA and ECDHE.

The biggest concern with ECDSA is probably that it's usually deployed with
the NIST P-256 (prime256v1/secp256k1).  Some find this suspect, and thus
we have other curves with different levels of trust.

Then we have EdDSA and the IETF/IRTF/CFRG Curve448 and Curve25519.
If we had to have an alternative to ECDHE-ECDSA-AES128-CCM8, having
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (https://tools.ietf.org/html/rfc7905 )

woudl be nice.  Having two or three "backup" algorithms in the
non-constrained side of the equation means that there can be innovation on
the constrained side.

This is what I would really like to have in a standards document.
This matters to the hardware planners both on the constrained side of things,
and also on the cloud side of things.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/iot-wg/attachments/20190124/f3e534f1/attachment.sig>