Additional points:
- The rationale for the current SSL 3.0 "SHOULD NOT" is that it "did not support strong cipher suites", just as for TLS 1.0. The document should be clear that allowing SSL 3.0 is much worse than allowing TLS 1.0, for a number of reasons including the following: 1. No support for TLS extensions (meaning, for example, that you can't use ECDHE). 2. SSL 3.0 CBC padding is unfixably broken (unlike with TLS 1.0, a complicated constant-time implementation won't save you; see in https://www.openssl.org/~bodo/tls-cbc.txt). - The rationale for the TLS 1.0 "SHOULD NOT" includes the following: "TLS 1.0 [...] includes a way to downgrade the connection to SSLv3". This seems poorly worded, or at least I can't figure out what you really mean. As written, it doesn't seem to make much sense -- *all* versions of TLS by design do support protocol negotiation down to SSL 3.0 (which, of course, is no issue for implementations that don't support SSL 3.0 at all). - Given that (SSL 3.0 and) TLS 1.0 is still allowed (even with a "SHOULD NOT"), the specification should describe 1 : n-1 record splitting (the improved-interoperability tweak of my original empty-record approach: instead of sending an empty plaintext record first to avoid predictable CBC IVs, send a single-byte plaintext record first), and make it RECOMMENDED for CBC ciphersuites in SSL 3.0/TLS 1.0. This is really more about TLS per se than about using TLS in applications, but in practice the BCP document is probably the best place to document this (and it seems within the WG charter, and in particular covered by this BCP's goal to provide "recommendations for improving the security of [...] implementations"). Bodo
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
