Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Benjamin Kaduk <[e-mail]>]

On 10/23/2017 01:42 PM, Ackermann, Michael wrote:
>  But as stated in several previous Emails, the fact that TLS 1.2 is still available,  does not mean that we won't  have applications, business units or other entities that require TLS 1.3 and we will need to manage, monitor and secure these, as well as older versions.

This seems sufficiently hypothetical so as to be non-actionable.

That is, I assume that any sufficiently large enterprise must have some
sort of architecture review process before a new system is deployed (and
if one does not, it seems highly unlikely to be secure).  There would
need to be some resolution of the conflict between those parties
"requiring" monitorability and those parties "requiring" TLS 1.3 before
such a system could get approved and approach deployment, so I feel
obligated to insert "require" into scare quotes and attribute no real
meaning to the statement.

As was stated previously, this is a case of being stuck between a rock
and a hard place.  While it is reasonable to investigate changing both
of the rock and the hard place, it seems unwise to presume that it is
one or the other specifically that must change.  You assert in a
different message that it would be very expensive and time consuming to
change "virtually every platform and application, not to mention all the
management, monitoring, and security platforms" (e.g., the "hard
place"), and I do not disagree.  It would also be expensive and time
consuming to modify the TLS 1.3 protocol (e.g., "the rock") in the
way(s) being proposed; unfortunately, the error bars on this cost
estimate are necessarily quite large so as to take into account the risk
of catastrophic breakdown of the security of the Internet.   It seems
pretty clear that various parties involved in this conversation are
applying different metric functions to weight these various costs, which
makes it hard to see a path that would appease everyone.

In that same "different message" you also mention that you have come to
expect backwards compatibility, but can you really expect backwards
compatibility without limit?  Does Windows 10 run MS-DOS executables? 
Can a Kerberos principal who last set their password using Kerberos 4
expect to interoperate in a modern Kerberos 5 deployment?  Can you still
log into a shell server via telnet?  There are many arguments in support
of backwards compatibility, but they are not universal, and history
provides plenty of precedent for security eventually overriding
backwards compatibility.  So where would you put the boundary on the
backwards compatibility for static RSA in TLS or equivalent
non-forward-secrecy mechanisms?  Would you propose infinite
compatibility in this space with no bound?  Ten years from now?  When a
quantum computer can quickly factor 2048-bit RSA keys?  There are no
doubt folks here would claim that the writing has been on the wall for
five years or more that static RSA was out and forward secrecy was on
the way in, and that now is the right time to draw the line and drop the
backwards compatibility.    In fact, there is already presumed WG
consensus for that position, so a strong argument indeed would be needed
to shift the boundary from now.  I won't say that no such argument can
exist, but I don't think we've seen it yet.

-Ben