Re: [TLS] Fixing TLS

[Bill Cox <[e-mail]>]

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

Bill