Re: [TLS] Fixing TLS

[Dave Garrett <[e-mail]>]

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <[e-mail]>
> 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