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

From: John Mattsson <[email-masked]>
Date: Tue, 1 Oct 2019 07:58:01 +0000

Kathleen Moriarty <[email-masked]> 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 think encouraging implementation of TLSv1.3 is good and important, but are there other ways besides deprecation?

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.

- The second thing is to do like 3GPP and mandate support for TLS 1.3 in new implementations and deployments.

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.

Cheers,
John

-----Original Message-----
From: Kathleen Moriarty <[email-masked]>
Date: Thursday, 26 September 2019 at 15:50
To: "Salz, Rich" <[email-masked]>
Cc: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

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

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Oct 2019 08:00:11 +0000

Martin Thomson <[email-masked]>; wrote:

>When we release a new version of something, we are sending a message:
>
>1. new implementations and deployments MUST include support for newer versions
>2. existing implementations and deployments SHOULD be updated to support newer versions

I agree very much with this summary and I would like to have it published somewhere. Take for example RFC 8261. It was published almost 6 years after RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and not DTLS 1.2. I think this is one of the lessons IETF should learn from the TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in the future? For an external viewer it must look pretty strange that IETF in Nov 2017 published an RFC relying on DTLS 1.0 and then 7 months later started working on a draft forbidding its use....

I would like to see something like the following statements published:

"New implementations and deployments MUST include support for TLS 1.3"
"Existing implementations and deployments SHOULD be updated to support TLS 1.3"
"Existing implementations and deployments SHALL support TLS 1.3 by January 1, 2024"

>> """The expectation is that TLSv1.2 will continue to be used for many 
>> years alongside TLSv1.3."""
>
>Some people have that expectation, but I think that John is right to challenge it.  >There remain reasons that people are sticking with 1.2 for now, but those reasons >are mostly to do with allowing time to flush out the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies.

I agree with Martin, and irrespectively of whether it is true or not, I do not see any need to have this sentence in an IETF draft. 

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Friday, 27 September 2019 at 02:03
To: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

    So I agree with Kathleen's conclusion: not to change the goals of the current document.  But there are changes that I think are necessary (and thanks to Daniel and John for highlighting these).
    
    BTW, I've moved this to the TLS working group, because this is an active topic there and I don't see anything in my email that SAAG needs to concern itself with.
    
    On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
    > 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. 
    
    That differs from my perspective.
    
    When we release a new version of something, we are sending a message:
    
    1. new implementations and deployments MUST include support for newer versions
    2. existing implementations and deployments SHOULD be updated to support newer versions
    
    When we deprecate an old version of something, we are sending a message:
    
    3. only use this old version if you absolutely have to
    4. you are encouraged to take active measures to remove the need to use the old version
    5. you have our support if you decide not to support this old version
    
    Now, "support" from the IETF is about as meaningful as you think it is.  And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ [RFC6919].
    
    In browser-land, we've decided to form a coalition when it comes to removing TLS 1.0/1.1.  3GPP have obviously got their own support group, which seems to be functioning effectively, which is great.
    
    > """The expectation is that TLSv1.2 will continue to be used for many 
    > years alongside TLSv1.3."""
    
    Some people have that expectation, but I think that John is right to challenge it.  There remain reasons that people are sticking with 1.2 for now, but those reasons are mostly to do with allowing time to flush out the vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.
    
    I would advocate for removing this statement and any residue of that sentiment from the draft.  It's speculation and, even if it were true, it conveys the wrong message.  The only message I would include is that one that is further down the document: "Any newer version of TLS is more secure than TLSv1.1."

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Oct 2019 07:02:26 -0400

On Tue, Oct 1, 2019 at 3:58 AM John Mattsson <[email-masked]>
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.
>

Right, so they are not saying TLSv1.2 can't be used at that time, only that
TLSv1.3 must be supported.

"It requires that TLS 1.2 configured with FIPS-based cipher suites be
supported by all government TLS servers and clients and requires support
for TLS 1.3 by January 1, 2024. "

This is a good goal and fairly reasonable given that a number of customers
are asking for TLSv1.3.  Government customers will drive this further in
the US.

>
> > I think encouraging implementation of TLSv1.3 is good and important, but
> are there other ways besides deprecation?
>
> - The first thing is to do like NIST and already now give implementors a
> date when support for TLS 1.3 is required.
>

We've never done that as far as I know?  SHould we?  Or should this be left
to documents like NIST's and other regulatory requirements that drive
customer purchasing decisions?

> new implementations and deployments.

The second is typical from the point of publication.  So back when I was an
AD, we were already looking for TLS mentions in drafts and once TLSv1.3 was
published, is when you switch from the prior version being required to
support for TLSv1.3 being required.  I'm guessing this continued
(especially with Eric as an AD for another year after I stepped down), but
I am not watching closely.

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

Unfortunately, things like that do happen, but shouldn't.  In some
instances, an explanation is made as to why an older version is required
and it's an exception.  Was that the case?  (Sorry I don't have the time to
research the old discusses and history of the RFC at the moment).

It's not the right thing, but with TLS versions, they usually stick out a
bit when you read a draft and it's an easy thing to catch if you're
skimming a draft as an AD with 400 pages of reading to get through for a
telechat.

Bets regards,
Kathleen

> Cc: John Mattsson <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>     > 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?
>
>     >    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
>     >

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Oct 2019 07:06:38 -0400

On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

> I agree very much with this summary and I would like to have it published
> somewhere. Take for example RFC 8261. It was published almost 6 years after
> RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and
> not DTLS 1.2. I think this is one of the lessons IETF should learn from the
> TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in the
> future? For an external viewer it must look pretty strange that IETF in Nov
> 2017 published an RFC relying on DTLS 1.0 and then 7 months later started
> working on a draft forbidding its use....
>
We have this already, I believe in new drafts.

> "Existing implementations and deployments SHALL support TLS 1.3 by January

Are you proposing a draft to state this?  If agreeable, this could be a
quick draft and support for 1.3 is a reasonable request to align with
requirements in industry.  I'm not sure if our statement will drive the
date as much as NIST's, but it couldn't hurt and I would be surprised if
there were any objections to this.

I don't think anything other than an RFC is the right approach, unless
there is an avenue I am not thinking about as having IETF consensus would
be what you'd want for it.

> >Some people have that expectation, but I think that John is right to
> challenge it.  >There remain reasons that people are sticking with 1.2 for
> now, but those reasons >are mostly to do with allowing time to flush out
> the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies.
>
> I agree with Martin, and irrespectively of whether it is true or not, I do
> not see any need to have this sentence in an IETF draft.
>

As for this sentence, we'll see where the discussion settles out - removing
or altering it.

Best regards,
Kathleen

>     So I agree with Kathleen's conclusion: not to change the goals of the
> current document.  But there are changes that I think are necessary (and
> thanks to Daniel and John for highlighting these).
>
>     BTW, I've moved this to the TLS working group, because this is an
> active topic there and I don't see anything in my email that SAAG needs to
> concern itself with.
>
>     Now, "support" from the IETF is about as meaningful as you think it
> is.  And you can s/MUST/really ought to/ and s/SHOULD/may wish to/
> [RFC6919].
>
>     In browser-land, we've decided to form a coalition when it comes to
> removing TLS 1.0/1.1.  3GPP have obviously got their own support group,
> which seems to be functioning effectively, which is great.
>
>     Some people have that expectation, but I think that John is right to
> challenge it.  There remain reasons that people are sticking with 1.2 for
> now, but those reasons are mostly to do with allowing time to flush out the
> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.
>
>     I would advocate for removing this statement and any residue of that
> sentiment from the draft.  It's speculation and, even if it were true, it
> conveys the wrong message.  The only message I would include is that one
> that is further down the document: "Any newer version of TLS is more secure
> than TLSv1.1."
>

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Oct 2019 13:19:37 -0400

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

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

    > in new implementations and deployments.

But, the IETF doesn't really write requirements like this.

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Daniel Migault <[email-masked]>
Date: Tue, 1 Oct 2019 16:37:13 -0400

Hi Kathleen,

> We have this already, I believe in new drafts.

The current wording does not, in my opinion, make the message clear in the
current draft. Maybe that is a perception of non native English speaker,
but there are probably three sentences that could in my opinion make the
message clearer.

>> I agree with Martin, and irrespectively of whether it is true or not, I
>> do not see any need to have this sentence in an IETF draft.
>>
>
> As for this sentence, we'll see where the discussion settles out -
> removing or altering it.
>
> Best regards,
> Kathleen
>
>>
>> Cheers,
>> John
>>
>> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies..
>>

---

From: "Christopher Wood" <[email-masked]>
Date: Sat, 05 Oct 2019 04:55:31 -0700

On Fri, Sep 27, 2019, at 1:45 AM, Stephen Farrell wrote:
> 
> 
> On 27/09/2019 04:50, Martin Thomson wrote:
> > On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
> >>>> """The expectation is that TLSv1.2 will continue to be used
> >>>> for many years alongside TLSv1.3."""
> >> 
> >> So is your proposed change to only remove that sentence?
> > 
> > I just checked, and it seems like the only thing the document says
> > along these lines, so yeah.
> 
> Grand so. Like I said I don't think it's a biggie so I've
> commented out that sentence in the GH version. [1]
> 
>  [1]
> https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt
> 
> BTW - for the chairs/AD - how are we doing on getting IETF LC under
> way? I realise the world won't end if this isn't super-fast but it's
> been 3 months since publication was requested which seems like a bit
> of a while.

Sorry, Stephen! I missed this question. It's in Ben's queue at the moment. Hopefully it'll go up to LC soon (and, in my opinion with no hat, with this proposed sentence removal).

Best,
Chris