Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Brian Smith <[e-mail]>]

On Fri, Oct 10, 2014 at 10:07 PM, Brian Smith <[e-mail]> wrote:
> There are four cases to consider:
>
> CASE 1: Client included the TLS_FALLBACK_SCSV, server forgot session
> state when it was upgraded. The result is an inappropriate_fallback
> alert.
>
> CASE 2: Client included the TLS_FALLBACK_SCSV, server (magically!!!)
> retained the session state across the server software upgrade. The
> result is an inappropriate_fallback alert.

There's an important thing to note about these two cases: They only
apply when the server is, or recently was, TLS intolerant. That is,
the client did a non-secure fallback due to TLS intolerance, then the
server was upgraded to support the TLS_FALLBACK_SCSV and/or a higher
version of TLS, and then the inappropriate_fallback is sent. If the
server wasn't already TLS intolerant, then CASE 1 and CASE 2 won't
happen. Thus, I think it is better to say tat clients MUST send the
TLS_FALLBACK_SCSV in the ClientHello whenever they decrease
ClientHello.client_version due to their TLS intolerance logic.

Also, the draft fails to state something that is obvious to us, but
which is better to state explicitly: The server needs to ensure it
isn't version intolerant, or else adding support for the
TLS_FALLBACK_SCSV will cause the server to stop working.

There are several non-obvious reasons why a server might seem like it
is "version intolerant" or "extension intolerant" even though it
generally supports version negotiation and generally parses extensions
correctly:

* I have seen modern servers act like they are "TLS intolerant" when
OCSP stapling is enabled and the server's certificate doesn't contain
an OCSP AIA URI. The fallback to SSL 3.0 "works" for them because
browsers stop sending the status_request extension. However, the
server actually does the version negotiation correctly, modulo this
OCSP stapling bug. The best solution to this is to get a new
certificate that has the OCSP AIA URI in it.

* I have seen some servers (e.g. from Cisco) that don't like certain
orderings of TLS extensions (especially the new padding extension).
Again, non-secure fallback to SSL 3.0 "works" for them because no
extensions get sent in the ClientHello. But, the servers actually get
the version negotiation correct, modulo this buggy extension handling.
The solution to this is to upgrade to the version of the server
software that Cisco hasn't released yet(!). (And, browsers should
probably find a workaround for this issue. See
https://bugzilla.mozilla.org/show_bug.cgi?id=998135#c11.)

* I have seen some servers where the hostname-specific TLS
configuration is broken, but where the generic non-host-specific
configuration works. These servers appear to be TLS intolerant because
they try to use the hostname-specific TLS configuration when the SNI
extension is given, and fail due to it being broken. When the browser
downgrades to SSL 3.0, the non-hostname-specific configuration is
picked up, and the handshake succeeds. Thus, the problem isn't in the
server's TLS stack's version engotiatoin at all, but rather in the web
server's configuration file. The solution to this problem is to fix
the fix the configuration file.

These types of issues, and other similar ones, need to be accounted
for when deploying TLS_FALLBACK_SCSV on the server. Because these
issues are relatively easy to fix, and relatively rare, the existence
of these issues shouldn't stop any server software vendor from
deploying TLS_FALLBACK_SCSV and enabling it by default. But, people
should be aware of these issues when diagnosing surprises.

Cheers,
Brian