Hi, one more reflection on this: - People have requested EDHOC as well as EAP with PSK authentication. For the first protocol run (i.e., not resumption) ephemeral key exchange should be a requirement. A PSK with ephemeral ECDH mode can be used for more than resumption.
Tero Kivinen wrote: > and doing Diffie-Hellman for each of them would be too costly I agree that was true in the past. Do you think that is still the case for an optimized implementation of modern algorithms running on new CPUs? As I wrote in draft-mattsson-tls-psk-ke-dont-dont-don’t: “Modern ephemeral key exchange algorithms like x25519 [RFC7748] are very fast and have small message overhead. The public keys are 32 bytes long and the cryptographic operations take 53 microseconds per endpoint on a single core AMD Ryzen 5 5560U [eBACS-DH]. Ephemeral key exchange with the quantum-resistant algorithm Kyber that NIST will standardize is even faster. For the current non-standardized version of Kyber512 the cryptographic operations take 12 microseconds for the client and 8 microseconds for the server [eBACS-KEM].” (running times on constrained IoT devices would of course be much longer) Cheers, John From: Tero Kivinen <kivi...@iki.fi> Date: Sunday, 29 January 2023 at 16:32 To: Rafa Marín López <r...@um.es> Cc: John Mattsson <john.matts...@ericsson.com>, l...@ietf.org <l...@ietf.org>, EMU WG <emu@ietf.org> Subject: Re: [Lake] EDHOC rekey Rafa Marín López writes: > Hi John: > - 2) Use PSK with ECDHE (similar to psk_dhe_ke in TLS) > > Let me also add here, as a reference, IKEv2. Basically, section 1.3.2 in RFC > 7296 shows a 1-RTT exchange including DH exchange and nonces to regenerate the > IKE security association. > > - 3) Use PSK with exchanged random values (similar to psk_ke in TLS) > > Curiously, when IKEv2 tries to generate key material for the IPsec security > associations (and not for the IKEv2 SA) allows just sending nonces (see > section 1.3.3 in RFC 7296), though there is also the possibility to include a > DH exchange. I mention this because EDHOC can be used to regenerate OSCORE > contexts. IKEv2 allows doing IPsec SA rekeys without Diffie-Hellman because there might be thousands of those between two gateways, and doing Diffie-Hellman for each of them would be too costly. I.e., it allows per SA decision whether you need PFS or not. If you are rekeying SA just because your traffic counters roll over, there is no need to do PFS. Note, in this context the Diffie-Hellman secret to protect IKE SA is considered as "long term secret", i.e., breaking that will allow you to see the IKEv2 SA traffic, thus break all the IPsec SAs negotiated over that IKE SA unless they did their own Diffie-Hellman. Doing IKE SA rekey will redo that Diffie-Hellman, meaning attacker need to break that new Diffie-Hellman secret again to allow it to break new IPsec SAs created after rekey. For IKE SA rekeys there was no point to do rekey without doing Diffie-Hellman, so thats why doing Diffie-Hellman there is mandatory. -- kivi...@iki.fi
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
