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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
