On Mon, Dec 11, 2023 at 06:38:05PM -0500, David Benjamin wrote:
> Protocol changes generally require both client and server changes to take
> effect. Pre-existing deployments, by simply pre-existing, will not have
> those changes. If we add, say, post-quantum options for TLS 1.2, it will
> benefit zero existing TLS 1.2 deployments. If we add post-quantum options
> for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
> why we make these changes. We make them to benefit *future* TLS
> deployments, e.g. when server operators update their software. Although it
> can be a slow progress, pre-existing deployments gradually cycle into
> updated deployments.
FWIW, I had already considered this, and in fact essentially agree with
this take on the tradeoffs. My point is mainly that there is legitimate
room for some diversity of opinion.
As you noted in your response, the PKCS1 barrier to TLS 1.3 adoption
that might be holding back some operators will be addressed. Another,
that likely won't is that negotiation of "psk_ke" is particularly
brittle in TLS 1.3, and in constrained environments DH on every
resumption could be problematic.
My personal list of pain points is short, others can probably think of a
few more. I actually don't object to the draft. Rather, perhaps
"over", reacting to Rob's apparent negative reaction to posing the
question of whether the draft was *necessary*.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
