On Wed, Mar 08, 2023 at 05:11:27AM +0000, Peter Gutmann wrote:
> I think a safer option moving forward is "scrap it and order a new one", just
> do an RFC with a new, single extension with unambiguous semantics that
> reintroduces the TLS classic session resumption, but done with TLS 1.3
> mechanisms. In other words just a standalone psk_ke in a new extension with
> a description of "if the client sends this, use it".
Right, basically support for "psk_dhe_ke" is an implicit default
requiring no negotiation, and support for "psk_ke" is requested by the
client and generally accepted by servers barring specialised security
requirements.
Sure that would have been great. But won't the usual objections (it
isn't turned up to 11) mean that unless you and I are the implementors
and it is my implementation talking to your implementation, the new
extension will have even thinner support?
I am tacitly assuming that the implementation community might be
somewhat more pragmatic than the WG, and be willing to improve the
behaviour of the current extension, or perhaps the "silent majority" of
the WG would in fact be willing be more pragmatic on resumption, but
haven't chosen to engage in this thread, and we could ideally even reach
some language in an update that recommends more liberal settings in
general, with punishment set aside only for the faithful who believe
they're sure to never stray, in case they do.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
