On Mon, Jan 08, 2024 at 11:52:53AM +0100, Hannes Tschofenig wrote: > > Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara: > > Your design proposal below is nice but the number of messages make it > less attractive (even though the use of this mechanism is likely for > devices where performance and bandwidth is less of an issue).
I think the number of messages is the smallest possible for bidirectional fresh key exchange over reliable channel (3 for non- crossed, 4 for crossed). However, there are some bandwith improvements: - In crossed case if groups match and group is symmetric (not PQC), then both sides immediately ack. Saves 2 key shares. - In crossed mismatch/asymmetric case, one side drops the request, and other handles it as non-crossed. Saves 1 server key share. AFAICT, after that, there are no more pareto improvements. The flows are (with server responding): <-- request --> <-- ack --> and <-- request --> <-- response ack --> However, this might not work at all in unreliable case (DTLS). Especially the symmetric crossed case, but even in the asymmetric case request getting delayed until after key exchange completes could cause nasty issues. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
