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

From: "Salz, Rich" <[email-masked]>
Date: Thu, 26 Sep 2019 13:02:36 +0000

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 :)

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 26 Sep 2019 09:50:22 -0400

Sent from my mobile device

> On Sep 26, 2019, at 9:02 AM, Salz, Rich <[email-masked]> wrote:
> 
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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Sep 2019 11:00:07 -0400

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Sep 2019 10:02:54 +1000

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.

> 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: Stephen Farrell <[email-masked]>
Date: Fri, 27 Sep 2019 01:52:03 +0100

Hiya,

On 27/09/2019 01:02, Martin Thomson wrote:
> So I agree with Kathleen's conclusion: 

Me too, FWIW.

> 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.
> 
>> 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.
> 
> 1. new implementations and deployments MUST include support for newer
> versions 2. existing implementations and deployments SHOULD be
> updated to support newer versions
> 
> 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."""

So is your proposed change to only remove that sentence?

Personally, I'm not that fussed. Including or omitting that
seems not a big deal to me. If the WG are however keen on
such a change that's fine too. OTOH, we've already done a
bunch of process-steps with this process-draft so I do
wonder if that change really amounts to a worthwhile thing.

Cheers,
S.

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 26 Sep 2019 22:38:36 -0400

On Thu, Sep 26, 2019 at 8:03 PM Martin Thomson <[email-masked]> wrote:

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

I think the reason John cc saag was that the request was more generic, that
is not only focused to TLS, but the current discussion is only TLS
focused.

> versions
> I agree that how it should be. That said, if everyone were adopting the
newest version, we would probably do not even need to deprecate oldest
versions which would be phased out by themselves. Forum or standard bodies
are good to define a direction for adopting new version and deprecating old
versions. However, outside these groups, updating a new version is seen as
deployment/development cost and as such, old version tends to remain until
it is explicitly deprecated.

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

> removing TLS 1.0/1.1.  3GPP have obviously got their own support group,
> which seems to be functioning effectively, which is great.
>
> 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 believe that for a significant number of deployed software the reason to
stick to TLS 1.2 is that it works with TLS 1.2,  TLS 1.2 is not deprecated
and still supported (=not deprecated). However I would be happy to be
wrong.

> 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."
>
> The opposite would be surprising, but I do understand your point. We could
remain focus on the deprecation, not the adoption of the newest version. My
motivation for explicitly push for TLS 1.3 was to remind your point 1) and
2). I think that would be useful to have these point in one way or another,
but that is only my opinion.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Sep 2019 13:50:43 +1000

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

> wonder if that change really amounts to a worthwhile thing.

I do.  Or I wouldn't have written the email.  Do you think that this is a valuable statement?  I think that it says that the IETF lacks confidence in the suitability of TLS 1.3 as a replacement for TLS 1.2.

If you want a smaller change, s/many years/some time/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Sep 2019 09:45:04 +0100

On 27/09/2019 04:50, Martin Thomson wrote:
>>>> """The expectation is that TLSv1.2 will continue to be used
>>>> for many years alongside TLSv1.3."""
>> 

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.

Cheers,
S.

> 
>> Personally, I'm not that fussed. Including or omitting that seems
>> not a big deal to me. If the WG are however keen on such a change
>> that's fine too. OTOH, we've already done a bunch of process-steps
>> with this process-draft so I do wonder if that change really
>> amounts to a worthwhile thing.
> 
> I do.  Or I wouldn't have written the email.  Do you think that this
> is a valuable statement?  I think that it says that the IETF lacks
> confidence in the suitability of TLS 1.3 as a replacement for TLS
> 1.2.
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 27 Sep 2019 11:07:05 -0400

Hi,

Maybe I am missing the point, but I do not see any reasons to not
explicitly recommend adoption of the latest version (i.e. TLS 1.3).

While the document deprecates old version, providing explicitly the status
of the non deprecated versions seems to me in scope of the document. As
such, clearly stating that TLS 1.3 or the latest version is expected seems
to me better, but I am happy to hear otherwise.

Removing the sentence that mentions TLS 1.2 and TLS 1.3 will coexist for a
long time, does not carry exactly the same message as explicitly
recommending the adoption of the latest version. I believe explicit
statement will help adoption of TLS 1.3.

To be clearer, I am providing the alternate text I had in mind. Of course
feel free to change the wording.

abstract:

OLD:

"""TLSv1.2 has been the recommended version for IETF protocols since 2008,
providing sufficient time to transition away from older versions."""

NEW:

"""The current recommended version for TLS is 1.3 and version 1.2 has been
recommended since 2008, providing sufficient time to transition away from
older versions."""

Introduction:

OLD:

NEW:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""

OLD:

NEW:

"""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. At the time of writing this document
this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly
RECOMMENDED. If TLSv12.2 were not supported yet, adoption of TLSv1.3 is
RECOMMENDED.  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.
"""

Yours,
Daniel

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Sep 2019 16:15:42 +0000

On 9/26/19, 11:51 PM, "Martin Thomson" <[email-masked]> wrote:

    
>    I do.  Or I wouldn't have written the email.  Do you think that this is a valuable statement?  I think that it says that the IETF lacks confidence in the suitability of TLS 1.3 as a replacement…
  
It is a statement of real-world deployment.  I am against removing it.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Sep 2019 10:10:51 -0700

Perhaps we could rewrite this text so that it reflects that we think this
is non-ideal.?

On Fri, Sep 27, 2019 at 9:16 AM Salz, Rich <[email-masked]> wrote:

> confidence in the suitability of TLS 1.3 as a replacement for TLS 1.2.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Sep 2019 17:24:04 +0000

I could even accept with “, unfortunately” :)

From: Eric Rescorla <[email-masked]>
Date: Friday, September 27, 2019 at 1:11 PM
To: Rich Salz <[email-masked]>
Cc: Martin Thomson <[email-masked]>, Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Perhaps we could rewrite this text so that it reflects that we think this is non-ideal.?

On Fri, Sep 27, 2019 at 9:16 AM Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

On 9/26/19, 11:51 PM, "Martin Thomson" <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=avjlNHHNBfovgxnF47PW747tAzpi2N7ARGWwftm4c8E&s=XdJ1ZBOBiFnJzrTs053x7X1ZFr2OXIQ1aWaqCL3Q_mY&e=>

---

From: David Benjamin <[email-masked]>
Date: Fri, 27 Sep 2019 15:06:18 -0400

I don't think the statement should be included at all. Were these documents
more of a WHATWG-style "living standard" model, it might make sense, but
IETF documents involve much more deliberation, take longer to update, and
are broader in scope. We should be careful about making statements about
upper bounds. Lower bounds are much safer. See also older TLS MTI ciphers,
which didn't age well:
https://tools.ietf.org/html/rfc5246#section-9
https://tools.ietf.org/html/rfc4346#section-9
https://tools.ietf.org/html/rfc2246#page-48

Even describing today's real-world deployment, the situation is more
nuanced than that statement implies. It's true that TLS 1.2 is unlikely to
go away anytime soon. But it has also been largely superseded by TLS 1.3.
If we design a new TLS-related feature, say certificate compression, some
new exporters, new encryption algorithm, etc., we will likely only target
TLS 1.3. There is little point in TLS 1.2 features which would require code
change to adopt because any 1.2-only deployment that can perform a code
change may as well use that code change to first switch to 1.3.

Even a statement like that has its caveats. For instance, there are some
use cases around client certificates where code changes in some components
are easy (TLS stack) and others are not (PKCS#1-v1.5-only signing
component). But over time, as dependencies clear (perhaps that signing
components finally get updated, or folks adopt
https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00), these caveats
will shift.

The situation also varies by the kind of deployment. For a typical HTTPS
deployment on the web, the statement about code changes is I think quite
solid. A small closed ecosystem could go further and migrate off TLS 1.2
today. Or if you are making a brand new application with no connection to
existing TLS 1.2 deployments, it would be quite reasonable to set TLS 1.3
as your baseline.

Thus I think the document should not try to describe this situation. The
deprecation states of TLS 1.0 and 1.1 have thoroughly solidified enough
that we're now deprecating them, hence the document. TLS 1.2's relationship
to TLS 1.3 is still actively evolving (RFC5246 has only been obsolete for a
year) and quite uneven. I don't think there is value in trying to pin
something down yet, beyond what we've already done, RFC8446
obsoleting RFC5246.

On Fri, Sep 27, 2019 at 1:24 PM Salz, Rich <[email-masked]> wrote:

> *From: *Eric Rescorla <[email-masked]>
> *Date: *Friday, September 27, 2019 at 1:11 PM
> *To: *Rich Salz <[email-masked]>
> *Cc: *Martin Thomson <[email-masked]>, Stephen Farrell <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=avjlNHHNBfovgxnF47PW747tAzpi2N7ARGWwftm4c8E&s=XdJ1ZBOBiFnJzrTs053x7X1ZFr2OXIQ1aWaqCL3Q_mY&e=>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Sep 2019 13:14:33 -0700

> been 3 months since publication was requested which seems like a bit

I had a run of several substantial events in my personal life earlier
this year, that let the queue of documents in "publication requested"
(https://datatracker.ietf.org/doc/ad/benjamin.kaduk) build up for
2-3 months.  Catching up to that has been slower, but I'm working on it.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Sep 2019 00:50:39 +0100

Hiya,

> this year, that let the queue of documents in "publication requested"

Sorry to hear that.

> 2-3 months.  Catching up to that has been slower, but I'm working on it.

Great, thanks.
S.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 27 Sep 2019 22:30:40 -0400

I would be more inclined to rephrase the text so that it reflects what we
think is ideal rather than what we think is non-ideal. I proposed three
edits to encourage to move to - or at least consider moving to TLS 1.3,
while still leaving some place for room to stay with TLS 1.2.

Yours,
Daniel

On Fri, Sep 27, 2019 at 1:12 PM Eric Rescorla <[email-masked]> wrote:

>>     > >> """The expectation is that TLSv1..2 will continue to be used for