Re: [TLS] An SCSV to stop TLS fallback.

[Wan-Teh Chang <[e-mail]>]

On Thu, Nov 28, 2013 at 4:21 AM, Bodo Moeller <[e-mail]> wrote:
> Everyone,
>
> the new I-D for TLS_FALLBACK_SCSV is now at
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

Bodo, Adam,

I read your -01 draft while reviewing your OpenSSL and NSS patches for
TLS_FALLBACK_SCSV.

I have some comments.

1. Why don't you also specify a TLS extension, which can be used when
we fall back to a lesser TLS version (but not SSL 3.0)?

I assume specifying only a SCSV is for simplicity.

2. I don't understand why you want the server to report an
inappropriate fallback only if the client drops below the server's
highest supported version.

This means an inappropriate fallback is not always reported to the
client, or it is reported to the client only after multiple fallbacks.

For example, suppose the server supports TLS 1.1 and the client
supports TLS 1.2.

If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
Reset (this middle box behavior was observed, not hypothetical), the
client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
but the server will then finish the handshake successfully.

On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
ServerHellos and injects a TCP Reset, the client will retry twice,
first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
Although the ClientHellos in both retries have the fallback SCSV, the
server will only respond with an inappropriate_fallback alert to the
second retry.

I think the draft should explain the rationale for this less strict
server behavior.

3. In the Security Considerations section, we have:

   However, it is particularly strongly recommended to send
   TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
   suites in SSL 3.0 have weaknesses that cannot be addressed by
   implementation workarounds like the remaining weaknesses in later
   (TLS) protocol versions.

It would be nice to name the weaknesses and workarounds explicitly.
The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
by record splitting, so I assume that's not the weakness you're
referring to. Are you referring to the CBC padding timing attacks?

Also, it seems that the main problem with downgrading to SSL 3.0 is
the loss of features and cipher suites that require TLS extensions,
such as Server Name Indication and ECC cipher suites. You already
mentioned that in the Introduction section. If the loss of these
features and cipher suites degrades security, it should be mentioned
in the Security Considerations section as well.

Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
record splitting workaround is effective). Perhaps these should also
be mentioned.

Wan-Teh Chang