Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Daniel Migault <[e-mail]>]

Hi,

My understanding of deprecating of TLS1.0 TLS 1.1 is that:
a) new software do not use these versions
b) existing software stop supporting these versions.

I am not sure how likely a new software is to use TLS 1.0 or TLS 1.1 with
TLS 1.2 and TLS 1.3 being widely deployed. It seems also a current best
practise to take the latest version, and I am also not sure implementers
considering TLS 1.0 or TLS 1.1 would read this document. That said, it
might be good the current text provide a stronger recommendation to
consider the latest version of TLS which is 1.3.

For existing software, the reason to maintain these old versions is, as far
as I understand, usually that the other side is composed of a legacy
software. The deprecation on the server side, expects legacy devices to
become enable to serve their purpose and that hopefully someone will unplug
them. I believe that the document could emphasise a bit more and recommend
to move to include TLS 1.3. In addition, I am not sure how relevant it is,
but if a  software is not yet supporting TLS 1.2 - that is supporting TLS
1.0 and TLS 1.1 - I believe that we should explicitly recommend it to move
to TLS 1.3.

"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""


"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

The text above may be interpreted that TLS 1.2 is fine for a long time and
there is not need to upgrade to TLS 1.3. It may be helpful to clarify that
version compatibility should also consider TLS 1.3. I woudl suggest
something around the lines:

Even TLS 1.2 and TLS 1.3 are expected to co-exist for years, with the
deployment of TLS 1.3, it is RECOMMENDED to envisioned the phase out of TLS
1.2 and start deploying TLS 1.3. In addition, software that do not support
TLS 1.2 are RECOMMENDED to implement only TLS 1.3.

Another way around may be to add a section: "Use TLSv1.3".


Yours,
Daniel


On Thu, Sep 26, 2019 at 9:50 AM Kathleen Moriarty <
[e-mail]> wrote:

>
>
> Sent from my mobile device
>
> > On Sep 26, 2019, at 9:02 AM, Salz, Rich <[e-mail]> 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=
> [e-mail]> 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
> >    [e-mail]
> >    https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>