On Fri, Dec 2, 2016 at 7:57 PM, Scott Schmit <i.g...@comcast.net> wrote:
> 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? > The wire format is one thing, but there is work that has been done at a much higher level referencing "TLS 1.3", e.g. TRON work: http://prosecco.gforge.inria.fr/personal/karthik/pubs/proscript-tls-tron-2016.pdf > 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. While more security analysis against whatever-the-new-TLS-is-called will certainly happen, I would imagine it would be split against whatever-the-next-TLS-version-is-called. And the thing is, a lot of the extant research about "TLS 1.3" is fantastic, so much so that I think it will be routinely cited. Certainly there will be new research, but much of the groundwork has already been laid. >From what I can tell, the main argument for changing the version is to *reduce confusion*. I am incredibly unconvinced rebranding TLS 1.3 to TLS 4/2017/9000 will actually accomplish the intended goal. A recent example of what sort of confusion I could see arise: ECMAScript. They moved from a numbered branding (ES6/ES7) to a year-based branding (ES2016/ES2017). People continue to use both, so now you have to maintain a mental mapping of which-version-to-which-year. The optimal solution to me as far as reducing these sort of mental gymnastics goes is to keep the version as "TLS 1.3" and drop the 1.x in the next release. This gets the "TLS 4" advocates what they want, just not right away, without renaming the current release at the last minute. -- Tony Arcieri
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
