Jim Reid <jim@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@sandelman.ca http://www.sandelman.ca/ | ruby on rails [