Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:

> http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03



> The current document seems still silent on the *KNOWN* problem when
> a client App has been skipping TLS versions on downgrade dance.
>


> MSIE 8 seems to be a browser that skips versions on downgrade dance.
> MSIE 8 on Win7 with TLSv1.2 enabled, dances like this:
>
>    TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext)
>

To recap what's been previously said, I don't think that a change to the
I-D is warranted.

- The (obvious) way to make this work is to not skip versions in the
downgrade dance. Often the downgrade will be happening because of a flaky
network, not because it is required with a specific server (or induced by
an active attacker): in that case, if the server does not recognize
TLS_FALLBACK_SCSV, it is more appropriate and generally better for security
to fall back to TLS 1.1 rather than to TLS 1.0.

- I do realize that some implementors may prioritize latency improvements
over the security gain here and hence may still prefer to skip TLS 1.1. I
won't encourage that behavior, but draft-ietf-tls-downgrade-scsv-03 doesn't
disallow it. In practice, the above sequence (after TLS 1.2, attempt TLS
1.0 with TLS_FALLBACK_SCSV) should generally work well enough because
support for TLS_FALLBACK_SCSV in servers with a maximum protocol version of
TLS 1.1 will probably remain rare. To maximize interoperability, such
clients should attempt TLS 1.1 with TLS_FALLBACK_SCSV later in the
downgrade sequence (i.e., after TLS 1.0 with TLS_FALLBACK_SCSV).

Bodo