On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: > > > > I'll be the bearer of bad news and tell you that your proposal has come up > > in multiple forms. I suggested a similar thing a while back and far before > > me others have as well. The chairs have, however, long declared consensus > > that we want to focus on a single new version not leaving out other more > > complex changes, namely latency improvements. The primary argument is that > > TLS version adoption rates are horrible and we would be far better suited > > to one major upgrade rather than incremental changes that would likely > > inhibit adoption of the more complex changes that we also need. (just a > > quick summary from my view; someone else can chime in here if they need to) > > > > I can't dispute this position, though personally I think it's not the best > > move. That said, if we were going to do a more incremental TLS version, > > doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up > > with would have been the way to go. That ship has sailed, and we're now > > well into TLS 1.3 development, so I guess I'm now on board with working to > > finalize the work that we're already doing (frankly, with a rename to TLS > > 2.0 being a good idea). If you can somehow drum up consensus to overturn > > the previous consensus, more power to you, but I think that's not likely to > > be the best route anymore. > > I'll just second what David said here. 0-RTT mode is here to stay, and I > don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is > a huge upgrade for users. The trick is doing this securely... > > My opinion counts little here, and TLS 1.3 is already nearly completely > defined, so I think it is too late for this discussion. However, if it > were not... > > A clean-slate TLS 2.0 which reuses as little as possible, and simplifies > life as much as possible, would have been preferable, IMO. I look at the > QUIC crypto code and then go back to the TLS/SSL code, and there is a night > and day difference in complexity. I think it is going to be painful for > some of us to watch the simple, clean QUIC crypto code move to the archives > and get replaced with TLS 1.3, which is surely going to be a substantial > bolt-on of code to the existing TLS 1.2 code base. It takes a super-genius > just to see all the potential pitfalls in the TLS 1.2 code as it is. I > think it will be even harder to analyze after the TLS 1.3 bolt-on. > Fortunately, we seem to have a large number of super-geniuses working in > TLS, much of the present company on this thread included :) However, if I > personally were making changes to the code, it would be maybe 4X faster to > do it in QUIC crypto, and 4X more likely that I would not introduce a > critical bug in the process. > > I think it is natural for many members of this email list to discount this > complexity issue in TLS 1.2/1.3, since many of the most brilliant > programmers see the existing code as not all that complex. For regular > mortal programmers out there like me, we would very much appreciate a > clean-slate effort with minimal complexity, and there are a lot of lessons > you folks have learned over the years that could be included. > > Maybe next time, in TLS 1.4? :-p
Personally, I hope this new version of TLS, save for possibly some minor update & extensions, is the final version. I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement. (the early documentation for QUIC was horrible, but the current work is vastly improved) As far as I'm concerned, TLS 1.3 is a transitional measure which should only be used in the medium-term by those who adopt new tech very slowly, and in the long-term phased out entirely. It is a very important transitional measure that needs to be done with as high a security and performance as possible, but a finite one nonetheless. (well, arguably, pretty much everything is, given a long enough timeframe ;) We have to get through the short-term to get to the long-term, though. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
