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

On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Martin Thomson <mt@lowentropy.net>; 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"
>
We have this already, I believe in new drafts.

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

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.

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

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

Best regards,
Kathleen

>
> Cheers,
> John
>
> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> on behalf of Martin Thomson <
> mt@lowentropy.net>
> Date: Friday, 27 September 2019 at 02:03
> To: "TLS@ietf.org" <tls@ietf.org>
> 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."
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org
>     https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 

Best regards,
Kathleen