Sent from my mobile device
> On Sep 26, 2019, at 9:02 AM, Salz, Rich <rs...@akamai.com> wrote: > > These are excellent points. Perhaps they can be squeezed into > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ ? > It's been waiting 90 days, a brief reset might not hurt :) > This would not be a brief reset and I’d prefer not to see them combined into the existing draft with WG agreement. With RFC7525, TLSv1.2 can be configured to be secure. I see the points made, but don’t see the urgency as obsolete is different from depreciation. I think encouraging implementation of TLSv1.3 is good and important, but are there other ways besides deprecation? 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? A vulnerability would speed things up, but I do hope that does not happen. Best regards, Kathleen > On 9/26/19, 8:18 AM, "John Mattsson" > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 > deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a > myriad subtle ways and should according to me optimally have been deprecated > years ago. > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time > not forbid use of TLS 1.1 as that would potentially break interoperability > with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson 3GPP > learned from this was the need to as early as possible mandate support of new > protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3 support > was mandated for network nodes in Rel-15 (2018) and for mobile phones in > Rel-16 (2019). > > At some point in time we will want to deprecate TLS 1.2. To enable that, > TLS 1.3 support should be mandated or encouraged as much as possible. I would > like to avoid a situation where we want to deprecate TLS 1.2 but realize that > it cannot be done because some implementations only support TLS 1.2. How can > IETF enable smoother and faster deprecations in the future? The browser > industry has a decent track record of algorithm deprecation and I hope to > soon see the following warning in my browser: > > “TLS 1.2 is obsolete. Enable TLS 1.3 or later.” > > Other industries have less stellar track records of algorithm deprecation. > > How can IETF be more pro-active regarding deprecations in the future? In > the best of words, nobody should be surprised when IETF deprecates a protocol > version or algorithm. NIST and similar organizations in other countries have > the practice to long time in advance publish deadlines for security levels, > algorithms, and protocol versions. Can the IETF do something similar, not > just for TLS but in general? For TLS, there are several things to deprecate, > in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2048, 224-bit ECC, > ffdhe2048, and non-recommended cipher suites (Static RSA, CBC, DH, NULL, > etc.) should be deprecated in the future. > > Cheers, > John > > _______________________________________________ > 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
