On Wed, Apr 12, 2023 at 01:18:17AM +0000, Peter Gutmann wrote: > On the subject of clarification, the update also needs to explain why PSK is > split across two separate extensions, psk_key_exchange_modes and > pre_shared_key, with complex and awkward reconciliation rules between then, > and why the PSK has to be the last extension in the client hello. I can't see > any reason for either of those two, which in particular for the latter one > means why would an implementation follow that apparently pointless > requirement? Is this codifying someone's implementation bug? Do demons fly > out of your nose if it's not the last extension?
For the first, I actually asked that very question during TLS 1.3 development. Psk_key_exchange_modes can appear without pre_shared_key. As for the second, the present method of computing binders (message truncation) requires pre_shared_key to be the last extension. While it would be possible to design ways of computing binders without such requirement, those methods would seem to be much more complicated. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
