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

[Bodo Moeller <[e-mail]>]

Brian Smith <[e-mail]>:

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.
>

This is a valid concern about the interaction of allowing fallback protocol
versions (whether using the normal version negotiation mechanism, or
fallback retries) with False Start. Obviously the False Start spec already
covers such aspects on a general level (do not use False Start unless the
symmetric cipher is cryptographically strong, etc.), but points such as the
one that older protocol versions may have *no* sufficiently secure cipher
suites at all are not made explicit.

This isn't specific to fallback retries and certainly not to the
TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
mechanism for protocol version negotiation), so I think an updated version
of the False Start specification would be the right place to set any strict
requirements for this. However, it would make sense to *mention* and
discuss this aspect in the TLS_FALLBACK_SCSV document (non-normatively).


[As for the specifics, while I think this isn't really for the
TLS_FALLBACK_SCSV specification to define, allowing False Start only with
the *one* most recent protocol version appears too strict. Specifically,
while deployment of a new protocol version is underway, clients may want to
use False Start both with this new version and with the previous version --
why downgrade the overall experience for those who enable the latest
protocol version?]



> 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.
>

Well, what makes the TLS_FALLBACK_SCSV mechanism particularly valuable is
that it can help protect you from attacks that no one is aware of yet. So
enumerating concrete attacks sort of would be missing the point:
TLS_FALLBACK_SCSV is mainly about those vulnerabilities that we *can't*
list there yet. I can tell you *now* how you would have benefited from
supporting TLS_FALLBACK_SCSV half a year ago.

The simplest argument in favor of preventing unwarranted fallback to
earlier protocol versions is that if we didn't think that the newer
versions were better, why would we be specifying them in the first place?

That said, the question whether the mechanism has relevance for weaknesses
other than those found in CBC cipher suites can be answered in the
affirmative. For example, if clients fall back to SSL 3.0 without TLS
extensions, they can't use ECDHE and thus may lose forward security.

Bodo