I agree that IANA registrations aren't a great place to constrain this. First, constraining the registry for TLS 1.2 and not DTLS 1.2 makes a lot of things very weird. For a feature that's TLS/DTLS-agnostic, like post-quantum, it helps no one to define it for DTLS 1.2 and not TLS 1.2. Most of the code and specification work is shared. Realistically, whether or not we formally freeze DTLS 1.2, we shouldn't post-quantum for DTLS 1.2. Part of the PQ transition for DTLS will be to get folks to DTLS 1.3. (Indeed Chrome uses DTLS for WebRTC and has not yet implemented DTLS 1.3, yet I have no interest in PQ for DTLS 1.2. For WebRTC PQ, we'll just do DTLS 1.3 first.)
I expect the DTLS waffling is transitory and attitudes to DTLS 1.2 vs 1.3 will catch up to TLS 1.2 vs 1.3 soon enough. But, while we're in that state, something as rigid as an IANA restriction is awkward. Second, while we don't intend to define new features for TLS 1.2, the draft says we may still apply "urgent security fixes". Restricting the IANA registration also restricts our ability to do that. Realistically, anything that involves a new extension will run into the usual considerations around existing TLS 1.2 servers not implementing it. But I could imagine, if we find another 3SHAKE, maybe deciding it's worth doing another EMS? (Maybe?? Honestly I'd probably just say, since you need a protocol change anyway, the fix is TLS 1.3.) On Tue, Jan 2, 2024 at 12:16 PM Eric Rescorla <e...@rtfm.com> wrote: > On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich <rs...@akamai.com> wrote: > >> I'm not Martin, but I believe that his point is that both TLS >> ciphersuites and TLS supported groups/EC curves permit registration outside >> of the IETF process based on the existence of.a specification. As long as >> PQC can fit into new ciphersuites and group types, then anyone can specify >> it for TLS 1.2, and it would in fact be TLS, just not standardized or >> Recommended. >> >> >> >> That is not what the just-adopted draft says. It says that except for >> ALPN and exporters that no new registrations will be accepted for TLS 1.2 >> and that new entries should have a Note comment that says “for TLS 1.3 or >> later”. This is a change in the current policy. It has always said this; >> see page 3 of [1]. >> > > I agree that's clear. Not sure how I misunderstood that, but in that case, > I think that this may be going too far, for the usual reasons why it's not > helpful to restrict IANA registrations of new stuff. > > Don't we expect this just to result in squatting. > > -Ekr > > >> >> >> At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has >> so little deployment[4]. This has complicated the wording of the above >> statement, which was raised at [2] and [3] >> >> >> >> [1] >> https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00 >> >> [2] https://github.com/richsalz/tls12-frozen/issues/10 >> >> [3] https://github.com/richsalz/tls12-frozen/pull/13 >> >> [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/ >> >> >> >> >> > _______________________________________________ > 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
