Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Salz, Rich wrote:
>> without all of the massive serious operational problems of
>> the current fallback-scsv proposal:
> 
> Can you elaborate on what this problems are?

The current document scratches the tip of the iceberg here:
   https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03#section-5


We know that part of the problem isn't TLS version/extension intolerant
servers, but version/extension intolerant middle-boxes.  These can be
client-side middleboxes, network middle-boxes or servers-side middleboxes.
In such cases, the server will only see handshakes with the
fallback SCSV asserted and, if it supports a sufficiently new protocol
will (have to) abort all TLS handshakes that reach the server in a
knee-jerk-reaction if it follows that proposal.  There is exactly zero
room for common sense behaviour left by this proposal.

We also know that there is a significant amount of installed-base servers
which never return any fatal SSL alerts before closing a network connection
after a TLS handshake failure (Microsoft IIS), because they're using
a transport-less TLS protocol stack and the application caller (not just
the TLS server-side implementation) will have to be changed in order to
make a fatal TLS alert newly appear on the network.

Aborting the TLS handshake is going to be the most stupid behaviour
in any case, because it will require a new TCP connection and a
new TCP handshake, plus any necessary app-level protocol negotiation
(HTTP CONNECT proxy traversal and pre-STARTTLS protocol handshakes)
to be repeated.


It would be so *MUCH* cleaner and easier when a different server behaviour
was specified and allowed (rather than rubber-stamping the knee-jerk-reaction),
such as allowing the server to continue the TLS handshake with
protocol version (ClientHello.client_version + 1) when ClientHello
contained the FALLBACK_SCSV among the TLS ciphersuites.

Such server behaviour would still allow the client to recognize that
the server could do better when offered, and allow the client to perform
sensible risk management -- becaus only the client knows what kind of
"better" protocol options it did not offer (remove) from his ClientHello
and how often it attempted to connect to the server.

Continuation of the handshake would also work much nicer (not require any
app-level changes) with servers such as Microsoft IIS, which currently
do not send fatal alerts back before closing the network connection.


(the only thing we would have to addtionally specify for servers
 continuing with (ClientHello.client_version + 1) is to skip doing
 the protocol version check on the RSA premaster secret for
 static-RSA key exchanges).


Another problem of the current proposal is that it addresses only
TLS version intolerance, but not TLS extension intolerance.  *BOTH*
exist out there.  And it doesn't really address reconnect fallbacks
that skip TLS versions on the downgrade dance.   MSIE 8 on Windows 7
will apparently perform the downgrade dance in the fashion
  TLSv1.2 -> TLSv1.0 -> SSLv3

This gets more important if the cause for handshake failures are
middle-boxes rather than the servers themselves.

-Martin