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

[Bodo Moeller <[e-mail]>]

Brian Smith <[e-mail]>:

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

Exactly, but the detailed recommendations should go into an updated False
Start I-D instead; I can do that.  Specifically, that spec could say that
if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
SHOULD be disabled for that handshake.  And then we'll also have to say
that the client similarly should not use False Start with any protocol
version for which it would send TLS_FALLBACK_SCSV in fallback retries
(since otherwise the former recommendation wouldn't achieve anything.)  The
TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
reminder that allowing False Start with older protocol versions can be
problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
can't address.

So, I believe that your suggestion for client behavior is absolutely spot
on. My point is just that the very same issue w.r.t. False Start and
version downgrades exists if the client doesn't do any fallback retries --
and those who implement such clients shouldn't have to read the
TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
into the False Start spec.


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

Right.  (Except that I don't think that you *disagree* with me on this.)


[...]

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

Here I don't agree. The downgrade to RSA is prevented by having *both*
(don't allow False Start here, *and* use the downgrade SCSV). Not allowing
False Start wouldn't have helped at all without the SCSV for fallback
retries, and using the SCSV wouldn't have been a complete solution if False
Start was enabled with legacy protocols.


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.


Right. I'll mention that potential surprise with False Start in
TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
the False Start specification.

Bodo