> > 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 >
Thanks for the reference but this draft paper does not count as a publication. Yes, there are other published papers that have appeared during the last year that use the name TLS 1.3, but I think academics will keep out of this (re)naming debate because it does not matter so much for us. We are already citing draft versions in our papers, because a proof for draft 10 does not carry over to draft 18. When the RFC comes out, we'll start consistently citing the published protocol, whatever it is called. Again, I'll keep out of the protocol name discussion, but I don't think the name will add too much confusion for academic works, or put another way, it will not reduce the confusion which already exists between various draft versions and the final RFC. > > >> 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
