On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. > Yes. This is what happens in a non-resumption handshake, so that the client can advertise what it supports. 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. > Correct. The idea is that the binder is computed on a prefix of the CH, as indicated in S 4.2.11.2. -Ekr > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
