Jeffrey Walton <noloader@xxxxxxxxx>:
Bodo Moeller <bmoeller@xxxxxxx> wrote:
> Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
> rollout will work out.
The WG should be solving problems that do exist; and not manufactured
problems or theoretical future problems that don't exist.
I can't entirely agree with second part of this statement: presumably everyone in the TLS WG is well aware of past design decisions that didn't take into account problems that didn't exist then but should have been foreseeable. (Related: I really shouldn't have had to write https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the fallback to SSL 3.0 in practice ... the "insecure fallback" to earlier protocol versions, including SSL 3.0, was a known "theoretical problem", and deserving of being addressed independently of concrete attacks).
I do agree with the sentiment, though: we shouldn't create Rube-Goldberg protocol mechanisms that don't serve a demonstrable purpose (and yet TLS arguably has a fair number of those). If the I-D was all about solving a theoretical problem with TLS 1.3, it shouldn't be accepted as an RFC (if only because then the TLS 1.3 specification would be the right place to specify the mechanism).
But of course, this isn't the case. The main point of the I-D is not to solve a problem with TLS 1.3. Rather, the specification's main purpose, at this time, is to solve problems with earlier versions. Notably, the mechanism from this specification has demonstrably protected users against vulnerabilities such as POODLE. It's just that the I-D achieves that by specifying a version-independent mechanism that *also* lends itself to addressing potential future problems with potential future protocol versions.
Bodo