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 =-

Attachment: signature.asc
Description: PGP signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to