John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: >> NIST has pushed back their date for US government organizations to >> have a plan to support TLSv1.3, what’s the driver to get ahead of that?
> NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I > think that is a good and ambitious plan. In fact it would be very good > if IETF agreed on the same requirement. I guess this is on outward facing web sites. Does it say which cipher suites are required, and certificate chains are required? (TLS 1.3 with RSA-1024+SHA1 certificates would be dumb) Does it say that *only* TLS 1.3 is to be supported? Does it say anything about outgoing connections supporting APIs and the like? > Yes, I think there is at least two things IETF can do: > - The first thing is to do like NIST and already now give implementors > a date when support for TLS 1.3 is required. But, it's so incredibly context sensitive. > - The second thing is to do like 3GPP and mandate support for TLS 1.3 > in new implementations and deployments. But, the IETF doesn't really write requirements like this. > This would avoid two thing that happened in the past. First, IETF > published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 > almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 > months after publishing a draft relying on DTLS 1.0, IETF started > working on a draft forbidding it’s use. Deprecating it from new work is not the same as removing it from implementations. My question above about *only* has to do with the knock-on effect. Entity XYZ keeps 1.2 (or 1.1) available because API FOO is used by entity BAR, which can not upgrade to 1.3 today. Entity BAR never experiences pain, never upgrades, and nobody is sure when/if they can turn off 1.2. This is a bit of a variation of the "Postel principal is bad" situation. One thing that entities like NIST could require is that compliant organizations report, in the years leading up to 2024, and after, to log and report the proportion of TLS version that connect. How can the IETF help? *An IETF standard for logging TLS connection parameters would help here* -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls