[TLS] The beauty of asking implementors

[Watson Ladd <[e-mail]>]

Dear all,

Rich Salz, after listing three options from conservative to radical,
"I put myself in the first group (except for SNI encryption, which
will get a separate post :), could be convinced to support something
from the second once it's written down, and am probably not qualified
to evaluate anything from the third group (few people are)."

AGL:"I would rather like to see a TLS 1.3 that is a tidying up of 1.2:
merging the various RFCs into one, editing and pulling in some of the
drafts that are floating around. The more significant changes could be
1.4."

Peter Gutman: "Absolutely!  I don't want to have to add yet another
parallel implementation
of a protocol that's just different enough that it's yet another set of code
and functionality to test, alongside SSLv3, TLS 1.0, and TLS 1.2.  All of the
previous updates have been compatible enough that you don't want to do a new
implementation, but incompatible enough that it's a different protocol.  Make
1.3 purely fixes for 1.2 and then start again with 2.0 so we can ditch all the
old baggage, complexity, and attack surface."

So that's the biggest site using TLS, the Chromium TLS person, and
Professor Gutman all stating their lack of interest in TLS 1.3 as
currently imagined. Currently the chairs are working backwards: fixing
the handshake (which has one secure mode) and not the record layer
(which has AES-GCM) first.

(Of course, the TLS 1.2 document describes neither: you need to look
at the Suite B for ECDHE_ECDSA, and somewhere else for ECDHE_RSA, and
AES-GCM)

I don't see how this is at all the right set of priorities. Fixing
known bugs should come before new features in any security project.
The implementers seem to agree with this perspective. I'm not seeing a
compelling argument from the chairs, explaining why they think TLS 1.3
should take priority over fixing TLS, just "trust us".

Sincerely,
Watson Ladd