Hi, For clarity to the WG I am summarizing the discussion of the "lesson learnt from deprecation" thread.
There is in my opinion a consensus that the current text does not emphasize enough that TLS 1.3 is the current version of TLS. There is also a consensus that the current draft limits the wording in emphasizing that TLS 1.3 obsoletes TLS 1.2 and is the current version to consider. The current texts that are subject to changes are the following: TEXT A: """The expectation is that TLSv1.2 will continue to be used for many years alongside TLSv1.3.""" Proposed alternatives are: a) remove the sentence b) leave the sentence as it is c) clarify the sentence for example with the following text: """ While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is strongly RECOMMENDED to consider the adoption of TLSv1.3""" TEXT B: """TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions.""" Proposed alternatives are: a) leave the sentence as it is b) clarify the sentence for example with the following text: """The current recommended version for TLS is 1.3 and version 1.2 has been recommended since 2008, providing sufficient time to transition away from older versions.""" TEXT C: """Deprecation of these versions is intended to assist developers as additional justification to no longer support older TLS versions and to migrate to a minimum of TLSv1.2. Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for protocols in their offerings. """ Proposed alternatives are: a) leave the sentence as it is b) clarify the sentence for example with the following text: """Deprecation of these versions is intended to assist developers as additional justification to no longer support older TLS versions and to migrate to a minimum of TLSv1.2. At the time of writing this document this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is RECOMMENDED. Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for protocols in their offerings. """ My personal opinion is to have some text that reflects what we think. Yours, Daniel On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk <ka...@mit.edu> wrote: > On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote: > > > > Hiya, > > > > On 07/10/2019 18:29, Rob Sayre wrote: > > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > > wrote: > > >> we can't "UPDATE" an I-D. > > > > > > Not true. If you need to refer to something that's been IESG-approved > but > > > still in the RFC queue, you can leave a note for the RFC editor to > update > > > the reference to the eventual RFC number. > > > > That would be an UPDATE on the eventual RFC and not on the > > I-D. And in this case, it'd IMO not be a good plan as a) the > > Recent IESGs have been taking the stance that it's weird to have "Updates:" > to a document that's not yet an RFC, mostly preferring to pull the document > in question back and get changed directly. But ... > > > relevant WG didn't want that, b) the I-D in question is part > > of a mega-cluster, so any dependency on it (as you suggest) > > risks loadsa delay if the cluster doesn't get unstuck, which > > can happen and c) our draft already stretches the header > > .... given that C238 is unblocked, dependencies-wise, that seems > questionable in this case. (The whole set of documents does have to go > through the xmlv2-->xmlv3 conversion, though.) > > > enough updating 85 RFCs - trying to add an I-D to that list > > would break tools and cause much pointless process-angst. > > > > Mostly (a) is the reason to not do it though. If you want > > to disagree with (a), then the right list for that would be > > the rtcweb list I guess, even though the WG is now concluded > > (which could, I guess, be (d);-) > > > > Overall, the cost isn't worth the benefit IMO. > > That's roughly where I'm landing, too, though as noted previously, it's > largely up to the sponsoring AD. > > -Ben > > _______________________________________________ > 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
