> 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.
If this were the path forward (and I doubt that it is), I would very much prefer Peter Gutman's evolutionary TLS 1.3. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, January 12, 2016 11:39 AM To: Bill Cox <waywardg...@google.com> Cc: tls@ietf.org Subject: Re: [TLS] Fixing TLS 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c882faa8317114da26f3e08d31b881439%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mMYoE%2bpBJpL6NKES01ZsFsN%2bwsf%2f8G7OwBhRkfWWDpI%3d _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
