Martin Thomson <m...@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"
"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 <tls-boun...@ietf.org> on behalf of Martin Thomson
<m...@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
