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

From: <[email-masked]>
Date: Tue, 1 Oct 2019 15:37:05 +0200

IMHO the problem with deprecation is not in the IETF but rather with the deployments. 

Ciao
Hannes

PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follow RFC 7925/7525.

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of John Mattsson
Sent: Donnerstag, 26. September 2019 14:18
To: [email-masked]; [email-masked]
Subject: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Oct 2019 22:20:57 +0000

>PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follow

Maybe the text could be updated to have one section of text for the web and
one for everything else, since they're totally, totally different
environments.  I was at a meeting last week to discuss upgrade mechanisms for
some globally deployed infrastructure and they were looking at a 2-3 year time
window to start the upgrade process, with completion by 2030 at the latest.

That's not a typo for 2020, it's 2030.

So the text needs to acknowledge the two different operating environments, the
web where you can replace anything you want at a drop of a hat, and the rest
of the world where it takes serious effort to make the change.  Moving from
TLS 1.0 to TLS 1.2 with EMS/EtM/LTS within ten years, for the non-web world,
is a practical goal.  Moving to an entirely new protocol in that time frame
(TLS 1.3) probably isn't going to happen.

Peter.

---

From: John Mattsson <[email-masked]>
Date: Sat, 5 Oct 2019 10:36:27 +0000

> PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follow RFC 7925/7525.

While TLS 1.2 and DTLS 1.2 can be configured to be secure, RFC 7525 is definitely not enough. RFC 7540 would be a good start, but also that would need to be extended with support of extensions like Extended Master Secret, Signature Algorithms, and Certificate Status Request to be considered fine in 2019.

Cheers,
John

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Oct 2019 13:40:27 +0000

John,  you reference RFC 7540 and I believe you wanted to refer to RFC 7925 instead.

RFC 7925 talks about the Extended Master Secret extension, Signature Algorithm extension, and
OCSP stapling.

Ciao
Hannes

-----Original Message-----
From: saag <[email-masked]> On Behalf Of John Mattsson
Sent: Samstag, 5. Oktober 2019 12:36
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Cheers,
John

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Oct 2019 08:39:39 -0700

I think that John was referring to the TLS usage profile in 7540, which is, I believe, still good advice.  The IoT profile in RFC 7925 also has good advice, but there is some bias toward things like CCM, which I don't believe are as widely applicable.

On Wed, Oct 16, 2019, at 06:40, Hannes Tschofenig wrote:
> While TLS 1.2 and DTLS 1.2 can be configured to be secure, RFC 7525 is 
> definitely not enough. RFC 7540 would be a good start, but also that 
> would need to be extended with support of extensions like Extended 
> Master Secret, Signature Algorithms, and Certificate Status Request to 
> be considered fine in 2019.
> 
> Cheers,
> John
> 
> 
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.