Subject: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

From: John Mattsson <[email-masked]>
Date: Thu, 26 Sep 2019 12:17:56 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Sep 2019 09:50:40 -0400

First, I think that we must recognize that the *IETF* does not have the same
       sectoral powers that 3GPP has.  It is entirely appropriate what 3GPP
       did, and they seem to have learned the lessons they needed.

John Mattsson <john.mattsson=[email-masked]> wrote:
    > 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.

I think that we can more easily deprecate these individual ciphers and cipher
suites than we can entire TLS version numbers.

The mere fact that we had to "hide" the TLS 1.3 version in the header the way
that did speaks volumes to the problems in what I'll call the "secondary"
security industry.   There are significant incentives from enterprises to
have companies come to "patch up" their broken systems.   If we want
enteprises to move faster, and move with us, then we will have to spend more
time addressing the issues that they have.  We may not like their problems,
we may even strongly disagree, but we have to keep them in the tent.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Sep 2019 09:50:57 -0400

Thanks for raising this discussion John, we have been struggling with this
in curdle as well and ipsecme. This is also a topic that I believe would be
useful to improve the security.

One aspect is that some implementers go to the IANA pages and believe that
everything on the pages is acceptable. I believe that it would be worth
adding some status associated to the code points. Currently, in most cases
a reference is associated to the code point. In some cases, the reference
is the RFC or document creating that created the code point in other cases,
the reference could be the RFC that deprecates the code point. There is no
specific rules, and that is probably something that would worth being
clarified. That being clarified, I still believe that it could be useful to
have a some sort of indication like a column that indicates whether the
code point is deprecated or not. This may involve additional terminology
depending on the level of information needed.

Another aspect would be to have software automatically checking which are
the code points status. This would of course only solve one side of the
problem as a device may end up on becoming silent, but that is probably
what should occur to non maintained devices.

Yours,
Daniel

On Thu, Sep 26, 2019 at 8:18 AM John Mattsson <john.mattsson=
[email-masked]> 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:
>
> 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
> countries have the practice to long time in advance publish deadlines for
> security levels, algorithms, and protocol versions. Can the IETF do
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Simon Bernard <[email-masked]>
Date: Fri, 27 Sep 2019 17:56:47 +0200

Hi,

   My 2 cents, I think a kind of overview page with status about 
protocols, ciphers an others would helps a lot. Something near of what 
is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
   This would be the page to know to be updated about security 
deprecation and planned obsolescence.
   If API was available to query this data, it could maybe be used by 
tools like : https://www.ssllabs.com/index.html

Regards,
Simon

Le 26/09/2019 à 15:50, Daniel Migault a écrit :
> Thanks for raising this discussion John, we have been struggling with 
> this in curdle as well and ipsecme. This is also a topic that I 
> believe would be useful to improve the security.
>
> One aspect is that some implementers go to the IANA pages and believe 
> that everything on the pages is acceptable. I believe that it would be 
> worth adding some status associated to the code points. Currently, in 
> most cases a reference is associated to the code point. In some cases, 
> the reference is the RFC or document creating that created the code 
> point in other cases, the reference could be the RFC that deprecates 
> the code point. There is no specific rules, and that is probably 
> something that would worth being clarified. That being clarified, I 
> still believe that it could be useful to have a some sort of 
> indication like a column that indicates whether the code point is 
> deprecated or not. This may involve additional terminology depending 
> on the level of information needed.
>
> Another aspect would be to have software automatically checking which 
> are the code points status. This would of course only solve one side 
> of the problem as a device may end up on becoming silent, but that is 
> probably what should occur to non maintained devices.
>
> Yours,
> Daniel
>
>
> On Thu, Sep 26, 2019 at 8:18 AM John Mattsson 
> <john.mattsson=[email-masked] 
> <mailto:[email-masked]>> 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:
>
>     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
>
>     [email-masked] <mailto:[email-masked]>