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

[Brian Smith <[e-mail]>]

On Thu, Oct 16, 2014 at 6:36 AM, Bodo Moeller <[e-mail]> wrote:
> 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 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).

If version downgrades during False Start are to be tolerated, then at
a minimum the security considerations of this draft must point out
that the mechanism is simple to subvert (partially, at least) when
False Start is used.

> [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?]

My point is that, because the clients that do the non-secure fallback
are also doing false start, without some version negotiation
restrictions for false start, the server still has no control over the
minimum version of TLS that will be used, even if they implement the
downgrade SCSV as specified. Right now it isn't a known emergency
because browsers (at least Firefox and Chrome) don't allow a MitM to
downgrade a connection to SSL 3.0 during false start. However, what if
the server administrator wants to be more cautious than browsers are?

It is true that, as the TLS 1.3 draft is currently written, browsers
will have to do non-secure fallback to TLS 1.2 often when they enable
TLS 1.3. I agree, given that current situation, that that is something
that should be allowed. But, I disagree that it should be allowed to
let a MitM downgrade a connection all the way to TLS 1.0 w/ the False
Start mechanism, especially when the server has implemented the
downgrade SCSV in an attempt to prevent that.

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

Besides POODLE and BEAST? I do think it would be good to see some more examples.

Anyway, I'm not asking you to enumerate every possible attack that is
prevented with this mechanism. I'm asking for the downgrade SCSV
mechanism to be improved to prevent more attacks, or at least for the
limitations of the dowgrade SCSV mechanism to be documented more
clearly.

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

No. When false start is allowed for RSA key exchange, the initial HTTP
request (including auth credentials), even if both sides implement the
downgrade SCSV correctly, an attacker can still force the client to
send the initial HTTP requests (with auth credentials) using a version
of its choosing and using RSA key exchange. In Chrome and Firefox, the
downgrade to RSA is prevented by their False Start policies, not by
the downgrade SCSV.

My point is that, without adding some restrictions on False Start, the
downgrade SCSV mechainsm is useless against any attack that would
succeed by being able to control what the client sends in its initial
application data. (Note that POODLE isn't such an attack, because it
only succeeds by being able to control what the server will decrypt,
not just what the client sends.)

Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
saying it is surprising that the downgrade SCSV doesn't prevent
version downgrades, and that should be fixed.

Cheers,
Brian