[TLS] Limited rollback attacks in False Start and Snap Start

["Brian Smith" <brian at briansmith.org>]

http://tools.ietf.org/html/draft-agl-tls-snapstart-00
https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

With current TLS, the client and server securely agree on how *all* the
application data is encrypted. With False Start  the server no longer has
any say in which cipher or which TLS version (in particular, TLS 1.0 vs. TLS
1.1 CBC handling) is used to protect the application data that the client
sends, given an active MitM. Similar considerations apply to Snap Start when
considering a servers' cipher suite preferences changing over time (between
connections) and considering that Snap Start doesn't specify how the client
chooses which algorithms to use. Note also that neither proposal provides a
mechanism for the server to securely indicate to the client that such
extensions should not be used, and a server cannot find out that the
extensions are in use until after the client has already sent application
data encrypted with the MitM-influenced TLS version and cipher.

With the current TLS standards, in the event of a break in any symmetric key
cipher, a TLS server would have been able to prevent all exploits of that
break for new TLS connections simply by disabling the cipher suites on the
server side. This is no longer an effective countermeasure given clients
that implement these proposals; instead, all implementations of these
proposals have to be modified and/or reconfigured.

Currently implementations of False Start (Google Chrome and soon Mozilla
Firefox 4) allow any protocol version 3.0+, and any cipher suite the user
has enabled with key size of at least 80 bits. A quick check indicates that
this includes RC2-128 (only in Firefox, disabled by default), RC4-128,
3DES-EDE, AES-128, AES-256, CAMELLIA (only in Firefox), and SEED (only in
Firefox). Note also that there many servers that already don't want RC2-128
and RC4-128 to be used already due to real and perceived weaknesses in those
algorithms.

Both proposals could be strengthened to be similar to standard TLS by only
allowing the client to use them after the client has received a signed
message from the server that (a) lists allowed cipher suites, (b) indicates
which of these optimizations the server allows, and (c) provides a time
limit on the usage of this information. Such a message would be similar to
the SMIMEEncryptionKeyPreference X.509 attribute, but mandatory instead of
optional, and preferably would exist outside of the certificate so that
standard certificates could be used. Also note that such a mechanism is
needed in order for Snap Start to be extended for key exchange methods other
than RSA key exchange anyway, in order to transmit the reusable (ECDH) keys.

Regards,
Brian