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

[Daniel Migault <[e-mail]>]

Hi Kathleen,

On Tue, Oct 1, 2019 at 7:07 AM Kathleen Moriarty <
[e-mail]> wrote:

>
>
> On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson=
> [e-mail]> wrote:
>
>> Martin Thomson <[e-mail]>; 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.
>

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.

>
>
>> "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 <[e-mail]> on behalf of Martin Thomson <
>> [e-mail]>
>> Date: Friday, 27 September 2019 at 02:03
>> To: "[e-mail]" <[e-mail]>
>> 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
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Best regards,
> Kathleen
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>