2021-11-04 11:12 GMT-04:00 David Benjamin <david...@chromium.org>:
> Indeed it's *because* there is still an existing 1.2 deployment that we
> should be judicious with backports. Today, nearly every TLS implementation
> needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it
> is not possible for a client to say "I implement xyz extension only at 1.3".
> That means anyone implementing a backported extension *must* implement and
> test it in 1.2, even though it'll be virtually unused. Existing 1.2 peers
> don't implement it and new peers will use it at 1.3.
What David mentions here resonates and is worth underscoring. Specifying an
extension for both TLS 1.2 and TLS 1.3 forces almost every stack to support it
at both versions. We don't get to choose "no, we only implement new stuff in
TLS 1.3", which as far as Go is concerned, is the policy we want.
I understand that IoT devices are not running dual stacks, but that's not the
point. This is an ecosystem cost analysis. If the extension is defined at both
TLS 1.2 and TLS 1.3, all dual stacks out there will need to support it at both
versions.
I think the condition in the charter that Sean mentioned is good, and should be
abided. If an extension is about TLS 1.2 compatibility or transition, or if
it's important not to fracture the ecosystem, it might be worth backporting; if
it's just convenient for stacks that have not updated yet, it should not.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
