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 <rs...@akamai.com> wrote: > I could even accept with “, unfortunately” :) > > > > > > > > *From: *Eric Rescorla <e...@rtfm.com> > *Date: *Friday, September 27, 2019 at 1:11 PM > *To: *Rich Salz <rs...@akamai.com> > *Cc: *Martin Thomson <m...@lowentropy.net>, Stephen Farrell < > stephen.farr...@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org> > *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 <rs...@akamai.com> wrote: > > > > On 9/26/19, 11:51 PM, "Martin Thomson" <m...@lowentropy.net> wrote: > > On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote: > > >> """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? > > > 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. > > It is a statement of real-world deployment. I am against removing it. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > 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=> > > _______________________________________________ > 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
