Subject: Re: [Uta] TLS BCP Review

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Aug 2014 23:25:56 +0300

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-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 16 Aug 2014 17:17:03 +0200

Hi Yaron et al.

Thanks for the update.

> list in favor of keeping SSLv3 (somewhat) allowed.

Just to reiterate why SSLv3 should be a MUST NOT: I guess most of you
have already noticed - at Black Hat USA 2014 there was yet another
attack presented that uses a downgrade to SSLv3 to be effective:
http://bh.ht.vc/

Will look through the attacks draft in the coming days.

Aaron