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

[Bodo Moeller <[e-mail]>]

Yngve N. Pettersen <[e-mail]>:

The SCSV proposal very likely will not "break the web", but my objection is
> that it will require updates to all the servers, and not just the clients,
> and thus take too long to deploy (case in point: 4 years after the Renego
> problem was discovered, 20% of servers are still not patched). Given that.
> 14 years after TLS 1.0 was released, about 1% of servers still only support
> SSL v3. I do not have high hopes of having SCSVs fully deployed in 15 years
> (unless client vendors decide to, or have to, "break the web").
>
> My suggestion have been to update the clients to refuse to use fallback
> when connecting to servers that implement the Renego patch. This have the
> benefit of using a proxy for correct version negotiation, which is already
> deployed on a majority of servers. The drawback of my proposal is that the
> proxy indication is not perfect; there is a small fraction of patched
> servers that are version and/or extension intolerant, and there is a much
> larger fraction of servers that are version intolerant for whatever version
> bytes TLS 1.3+ will use. Some will call the first group as "breaking the
> web", while most will probably agree that the second can definitely be
> called "breaking the web".


> The question is, if client vendors agree to "bull through" and refuse to
> fall back, will the server vendors and web site operators fix their
> implementations, and if so, how quickly? The best option in such a scenario
> would probably be a coordinated same-day release  (alternatively flipping a
> flag) of updated clients, particularly browsers, so that web sites cannot
> use the "switch browser" "advice" for fixing the "browser bug". (Flipping a
> flag might be the better option, since this will allow the updated browsers
> to gain a sufficiently large marketshare before changing the behavior)


As I've mentioned, the two options are not mutually exclusive, so I think
you are constructing a false dichotomy.  We can start to use TLS_FALLBACK_SCSV
ASAP to improve security *ASAP* for connections to *those* servers that do
get updated (80% or even just 10% is better than 0% -- if only the most
important servers that users trust get updated, that's something).  Servers
that aren't version tolerant or extension tolerant will still be just as
broken; having TLS_FALLBACK_SCSV specified doesn't mean that clients are
generally *expected* to fall back, so doesn't affect plans for a fallback
flag flip day or anything like that.

Bodo