Hi Bodo,
Sorry for the late response, but I am now going through the various
comments on the BCP draft in order to publish the next version "real
soon now". Please see below.
Thanks,
Yaron
On 07/23/2014 05:27 PM, Bodo Moeller wrote:
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).
I included your point #1. Point #2 is kind of splitting hairs, given
that we are still seeing padding-related attacks in TLS 1.2.
- 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).
I agree, and will remove this text (as well as "TLS 1.1 [...] prevents
downgrade attacks to SSL," in the next paragraph).
- 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.
First, I concur with Aaron's opinion and would like to change SHOULD NOT
to MUST NOT on SSLv3 (but not TLS 1.0), unless there's outcry on the
list in favor of keeping SSLv3 (somewhat) allowed.
Second, I wouldn't want to add the 1:n-1 splitting to this draft, for at
least two reasons:
- The draft is targeted at future implementations. I think documenting
TLS 1.0/1.1 mitigations and all the past baggage associated with these
versions (cipher suites, key lengths etc. etc.) would delay this draft
for months and would defocus it.
- I don't think anybody reading this draft would actually make such
fundamental changes to their TLS 1.0 code. If they'd cared about it,
they would have patched their systems sometime during the last 3 years.
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
