+1 Should consider analysis and recommendations by NIST’s LWC project too https://www.nist.gov/programs-projects/lightweight-cryptography Panos
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, March 19, 2018 7:15 AM To: John Mattsson <john.matts...@ericsson.com>; ace@ietf.org Subject: Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT Here is a relevant document: https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-00 From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of John Mattsson Sent: 19 March 2018 11:11 To: ace@ietf.org<mailto:ace@ietf.org> Subject: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
