There's also the fact that the TLS 1.3 was published in August 2018, but DTLS 1.3 wasn't published until April 2022. So, it is kind of reasonable to allow some extra time here.
The WG could say this document doesn't apply to DTLS. Another choice would be to say that it does apply to DTLS, but the WG will continue to accept work for DTLS 1.2 that is DTLS-specific. The aim here being that DTLS is not used as an excuse to continue to work on 1.2. thanks, Rob On Sun, Aug 6, 2023 at 8:28 AM Achim Kraus <achimkr...@gmx.net> wrote: > I don't have a complete overview, but AFAIK: > > - wolfSSL (C) has DTLS 1.3 > > - mbedTLS (C) for now doesn't support it > > - pion/dtls (GO) for now doesn't support it > > - Eclipse/tinydtls (C) doesn't support it > > - Eclipse/Californium (Java) doesn't support it > > best regards > Achim > > Am 06.08.23 um 17:01 schrieb Salz, Rich: > > Quoting https://github.com/richsalz/tls12-frozen/issues/7 > > <https://github.com/richsalz/tls12-frozen/issues/7> raised by Jonathan > > Lennox, in its entirety: > > > > “Given the slow progress of implementations of DTLS 1.3, I think this > > draft needs to be clear that this feature freeze applies only to TLS 1.2 > > proper, not DTLS 1.2. > > > > “For example, I would be very sad if any new DTLS-SRTP protection > > profiles could only be negotiated with DTLS 1.3. > > > > “This may have implications for the IANA instructions section, for > > registries that are shared between the two protocols.” > > > > Does the WG have any vews? I know OpenSSL isn’t doing DTLS 1.3 right > > now, but is the industry overall lagging? Should we allow changes to > > DTLS 1.2? > > > > > > _______________________________________________ > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
