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

[John Mattsson <[e-mail]>]

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