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

[[e-mail] (Martin Rex)]

Adam Langley wrote:
> Sad as it is, in order to work on public Internet all browsers
> implement TLS fallback: in the event of a handshake failure they will
> retry the connection with a lesser SSL/TLS version.
> 
> This means that an active attacker can disable AES-GCM support and,
> ultimately, ECDHE if they push the browser back to SSLv3. It would be
> good to finally do something about this.
> 
> Thus I'd like to propose the design of an SCSV with which we can move forward:
> 
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.


We keep this proposals for newly creating interop problems keep
coming up on this list?

How about instead fixing the negotiation so that AES-GCM&AES-CCM
can be sent in whatever ClientHello there is (including SSLv2)
and an additional SCSV to signal availability of a specific subset of
ECDHE that can be used without a TLS ECC extension, such as the subset
that is supported by Windows 7+?


If there is a problem in negotiating what _we_want_to_do_, because the
installed base does not like the kind of negotiation that was originally
proposed to be used, then the pragmatic engineering approach will be
to define an alternative negotiation of at least a useful subset
that will be compatible with the installed base, and which will not need
to be stripped from a "conservative fallback handshake" -- and therefore
will be resilient to downgrade attacks, and cope with retarded middle boxes.


-Martin