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

[Brian Smith <[e-mail]>]

On Thu, Sep 25, 2014 at 9:00 PM, Joseph Salowey (jsalowey)
<[e-mail]> wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

It seems like the draft should also advise clients that they MUST NOT
do the False Start optimization if the server does not choose the
maximum version of TLS that they support. For example, if the server
chooses a version less than ClientHello.client_version, or if the
client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
start. Currently the draft says nothing about this. Because of False
Start, there are several downgrades that are still possible even with
the current downgrade-SCSV-enabled Chrome and Firefox, for example.

1. During a False Start handshake, the MitM can remove the
TLS_FALLBACK_SCSV from the ClientHello, so that the server cannot
detect the version downgrade. The client will only be able to detect
this tampering once it has processed the server's Finished message.
But, by then, it has already sent application data using the
downgraded version.

2. Similarly, the MitM can tamper with ClientHello.client_version in a
ClientHello regardless of whether it has the TLS_FALLBACK_SCSV in it,
and a client that does the False Start optimization won't notice the
tampering until after it has sent some application data.

3. Even without tampering with TLS_FALLBACK_SCSV or
ClientHello.client_version, a MitM can easily degrade the cryptography
on a connection. For example, let's say a server supports ECDHE with
P-256 and DHE with 1024-bit keys. A P-256 key is much stronger than a
DHE-1024 key. If an attacker removes P-256 from the client's
supported_curves extension, then the server will choose a DHE-1024 key
in the handshake, even with TLS 1.2. This type of downgrade could have
a much bigger effect than a downgrade from TLS 1.2 to TLS 1.1.

In all these cases, the server won't process the client's application
data, because the server will detect the tampering before processing
it (because it processes the client's Finished message before it
processes the application data). But in theory there may be attacks
where just sending the initial application data in a downgraded
version would be a security problem. For example, when it is clear to
everybody that SHA-1 is broken, non-secure downgrades from TLS 1.2 to
TLS 1.1 alone will be a severe security problem. If these attacks are
out of scope, then the document should say so. Otherwise, they should
be addressed.

In summary, the way it is defined, the downgrade SCSV is only helpful
in preventing a limit number of unspecified downgrade attacks when
used in conjunction with False Start. Also, the draft is based on the
premise that preventing version downgrade is useful for preventing
some cryptographic attacks, but it does not substantiate that. POODLE
and BEAST are evidence that the mechanism helps for some attacks. But,
is this mechanism actually effective for preventing any other class of
attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
cipher suites? The answer to this should be in the security
considerations.

I don't think it makes sense to consider False Start out of scope for
this, because all the browsers that are doing the non-secure version
fallback are also doing the False Start optimization.

Cheers,
Brian