Re: [TLS] An SCSV to stop TLS fallback.

[Bodo Moeller <[e-mail]>]

Marsh Ray <[e-mail]>:

> ClientHello.client_version
> >    The version of the TLS protocol by which the client wishes to
> >    communicate during this session.  This SHOULD be the latest
> >    (highest valued) version supported by the client.
>
> That sounds to me like the client MAY retry with record.version={3,0},
> but it SHOULD still send ClientHello.client_version={3,3}.
>
> So for clients that follow RFC 5246 recommendation, what is gained by
> sending TLS_FALLBACK_SCSV?


In this case, TLS_FALLBACK_SCSV is not sent.  TLS_FALLBACK_SCSV is all
about fallback connections in which the client deviates from the above
recommendation, and sends a lower ClientHello.client_version (i.e.,
pretends that it doesn't actually support the latest protocol).  That's
something that clients actually do, because following the RFC
recommendation doesn't allow them to interoperate with all servers in
practice, unfortunately.



> Why couldn't we instead recommend that
> servers reject with *any* connection attempt for which
> ClientHello.client_version < "highest version supported by the server" ?
>

I think you haven't thought that through.  If we did that, it would render
version negotiation pretty much useless: you couldn't ever upgrade servers
to a new protocol version before *all* clients have been upgraded to
support that version.


The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
> is that servers are not actually in a position to know the highest
> protocol version that the client supports.
>
> Thus a server would have to refuse *any* connection for which the
> client sends TLS_FALLBACK_SCSV set.
>

I don't follow.  Servers would refuse those connections for which the
client (1) sends TLS_FALLBACK_SCSV and (2) doesn't advertise support for
the server's highest supported protocol version.  They don't need to know
the highest protocol version actually supported by the client.


Sending a flag to say "oh by the way I'm lying about my highest
> version" is not a complete fix.
>

It's obviously not a *complete* fix, but it's a fix that addresses relevant
security problems, *and* can actually be deployed (right now, that is,
without having to fix every broken device on the internet first), *and*
does not get in the way of a complete fix.



> I only see one correct solution: ripping out this auto-downgrade
> logic from clients and putting these broken servers and middleboxes
> on notice that they have no place on a secure network.
>
> Only then will environment begin to heal and as it does page load
> times would become a bit faster.


That's the theoretically correct, non-kludgey solution.  However, the
reality is that client implementers have found it necessary in practice to
implement protocol fallback strategies to improve interoperability (and
users tend to prefer bad latency over unresolvable connection failures; I
fear that trying to explain some game theory on browser error pages
wouldn't help).  In case we manage to evict every server from the internet
that doesn't tolerate TLS 1.2 Client Hello message, that need would go away
for now -- but as soon as we start to deploy TLS 1.3, we might then find
out that new servers are around that work fine with TLS 1.2 but don't
tolerate TLS 1.3 Client Hello messages, and we'd be back to square one.
 There are some things we could try to prevent that, but if this Correct
Solution[TM] doesn't work out, it'll be good to have TLS_FALLBACK_SCSV
around as a backup.

Bodo