I strongly support Carsten’s suggestion to have a coordinated effort to produce updated profiles for the use of crypto algorithms in IoT. I think the work should include at least TLS, DTLS, COSE, and X.509 and take into consideration the hardware acceleration available in (future) devices. Should also look if there is a need to update X.509 profile in RFC 7925, any new IoT profile should be applicable to both TLS and COSE.
How do we get this started in a way that applies to all IETF groups using crypto? I would be happy to help with this work. Some quick thoughts: - Curve25519 is already implemented a lot, but needs to be differentiated from Ed25519 which is not implemented as much (yet) and may require CA support for certificate based deployments. Curve25519 and Ed25519 has a strong potential to lower latency, storage, memory, and battery consumptions in IoT devices. There was earlier vendors stating that curves with a cofactor caused problems for older hardware. My understanding is that this has now changed, at least the UICC vendors in 3GPP has stated that curve25519 works on their current hardware. - ChaCha20-Poly1305 is only standardized with 128-bit tags and therefore not very well suited for IoT. Like GCM, Poly1305 is not very well suited for truncated tags. AES_128_OCB_8 only requires half the amount of AES operations, but AES is not drawing much power compared to transmitting, listening, and receiving radio, so any update from AES_128_CCM_8 might not be worth it. I think 64 bit tags is a good compromised between overhead and security for IoT. - PRF. TLS 1.3 used HMAC with SHA-256, RFC8247 specifies PRF_AES128_XCBC for devices not having SHA. - Hash algorithms, Ed25519 is as far as I known standardized with SHA-512/256. IoT deployments of TLS and DTLS typically use SHA-256. Cheers, John
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
