> If the client is happy with either X25519 alone or X25519Kyber768, why not > send shares for both in the first ClientHello? >
This is what Chrome does, and what we do if the user opts for "preferred" mode. [1] Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a > blessed implementation choice, or conversely disrecommends it and explains > why. > Ah, you mean using the same X25519 key in both the X25519 and Xyber keyshare? We do not use that optimisation, but I do not see anything wrong with it from a protocol perspective. I would not want to encourage it, as it complicates code to generate keyshares as it crosses abstraction layers. Best, Bas [1] The issue is, as I described in my previous e-mail, that a small fraction of origins breaks on a large ClientHello. Whether we send X25519 along with X25519Kyber768 in the CH doesn't make a difference. It does prevent issues with origins that have broken HRR, and do not support Kyber.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
