I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be around for quite some time, but that *does not mean it is worth adding new features to TLS 1.2*. Those two statements are not directly related.
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. So when we decide whether to make a change to TLS 1.2 or TLS 1.3, the pre-existing deployments of both protocols are irrelevant. What matters is what will be used in new TLS software. At this point, now that TLS 1.3 is well-established, we should broadly expect new TLS software to be TLS-1.3-capable. Thus is it not worth our time to backport such changes to TLS 1.2. When I say "our", I don't mean just this working group, but also TLS implementers, application software that configures TLS implementations, and server operators who must somehow navigate the sea of options that comes from everyone else's indecision. Together, those costs are significant. More than that, we (the WG) should communicate this expectation. We did it once by publishing RFC 8446 and obsoleting RFC 5246. hence this document. But communication is hard, and now that the expectation is stronger, we should repeat it more strongly. There will always be stragglers and misunderstandings. Perhaps some more obscure TLS implementation has yet to implement TLS 1.3. (Or DTLS 1.3.) Perhaps some application has a hardcoded TLS 1.2 setting that needs to be updated. Perhaps some config files are stale. Publishing this document helps clear up what was already the WG's expectation. If it reminds a chunk of those folks to move to TLS 1.3, it will have been worthwhile. That is also why mentioning PQC is valuable, as it is the extension that is most likely to be on server operators' minds. Finally, communicating this is useful to us. Perhaps some new deployments are TLS 1.2 not out of inertia, but because something in TLS 1.3 inadvertently made migration difficult for those folks. In that case, us publishing this document helps invite such feedback. For example, draft-ietf-tls-tls13-pkcs1 addresses a migration challenge. (That specific example long predates this and, judging by the list discussion in 2019, it was perhaps a little ahead of its time, but we all got there eventually. :-D) This has nothing to do with raising the floor. This is about not bothering to start a new, shorter tower on the side while we raise the main ceiling. On Mon, Dec 11, 2023, 16:58 Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote: > > > PS - I have to say, not in this message, but sometimes it seems like the > > goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws > in > > TLS 1.2 that the draft describes are desirable. If that's the case, > > participants are not working toward the same goal. Writing down the > > consensus seems worth it. > > For what it is worth, my agenda/perspective has never been to weaken > encryption. Rather, it has always been about making usable encryption > ubiquitous. While we continue work on raising the ceiling, one can be > legitimately weary of raising the floor so high that encryption is > unusable, and communication happens in the clear instead. > > Given that TLS 1.2 will be around for quite some time, it is not obvious > that a feature freeze will in practice improve security. It is good > that there's ongoing effort to make TLS 1.3 better, and I accept that it > may well not be possible to deliver on required TLS 1.3 work and to also > make some occasional modest improvements to TLS 1.2, but if the goal is > to deliver secure products to users, a realist might accept that TLS 1.2 > is likely to continue to be used for some time, and that those users > could be better served if some improvements continued to take place. > > The contrarian possition of course assumes that such improvements > wouldn't be a significant drain on scarce resources. That assumption is > a matter for debate, and the "right" trade-offs are not completely > obvious. Some difference of perspectives can be expected. > > Whatever else we do, we should not default to questioning the motives of > others who would make somewhat different tradeoffs. Worry more when > everyone is in violent agreement, perhaps something is then being > missed. > > -- > Viktor. > > _______________________________________________ > 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
