On Fri, Dec 02, 2016 at 02:16:16PM -0800, Tony Arcieri wrote: > On Fri, Dec 2, 2016 at 1:21 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> > wrote: > > > The change was proposed long ago, and deferred by the chairs until now. > > This > > is just another variant of the inertia argument. > > > You keep dismissing this argument out of hand, but I think it has merit. > > I think we can all admit the decision to rename SSL -> TLS is a mistake (to > the point people are proposing to retroactively re-rename TLS back to SSL). > > There is now a huge body of work which calls the protocol "TLS 1.3" which > will be cited for years to come. You wrote this whole body of work off as > the concern of "TLS WG and a small number of people who interact with it" > as if a move to a different version number comes at zero cost almost as if > this work doesn't matter, but I have a different view: this is one more bit > of errata in exactly the same vein as the SSL -> TLS move which anyone > consulting this body of work will have to contend with. > > You will no doubt disagree, so I'm simply saying it for posterity: keeping > the version TLS 1.3 is the least confusing option, IMO.
SSL 3.0 was defined in November 1996 (20 years ago). RFC 7568 (sslv3diediedie) was published in June 2015. That's about 18.5 years. TLS 1.0 is still in use, it was standardized in January 1999. It's not dead yet, but there has been talk of it. That's almost 18 years ago. So these protocols tend to last multiple decades (granted, this is a small sample size, but it's what we've got). This draft has been in development since April 2014, 2.6 years ago. Over that time, the wire protocol has changed multiple times and incompatibly. So not even all of that 2.6 years of details is still applicable to the protocol we're going to publish as an RFC. So why would mixing up searched for the final protocol with the draft versions be a good thing? Development versions get new names when they get delivered all the time. Frankly, at $DAYJOB, development versions are always different than the final delivered version, by definition. Doing otherwise is poor version control. The volume of work that will be published in the hopefully 18 or more years that this draft is in deployment will dwarf the current body of work. If it doesn't, then we will have completely failed. Finally, at the top of every internet draft, the IETF states: > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." So, no, we have *not* been calling the next version of TLS "TLS 1.3" for 2.6 years. We have been calling it "a work in progress, subject to change at any time." Anyone doing otherwise is arguably as confused as those who don't even know what TLS is. And there are a lot more of the latter than the former. But no, I would not support calling the next TLS version "SSL 4/2017" -- the harm of invalidating the "SSL is broken, TLS is (more) secure" advice is too great. I'd support calling it RSSL (really secure ...) before I'd support that. -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
