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

[Manuel Pégourié-Gonnard <[e-mail]>]

On 05/12/2013 00:05, Marsh Ray wrote:
> So if a fallback situation was a slow-loading lousy page experience
> before, what's it going to be after legitimate servers implement this
> logic? Will servers actively *refuse* legitimate client's retry
> connections? If so, isn't this just taking an intermittent
> slow-failure situation and converting it to an even slower but
> guaranteed interop failure? If not, what good will downgrade
> protection logic be?
> 
It seems to me Adam already answered this argument, and his point was that
browsers don't retry plain HTTP connexions anyway, so the situation with
TLS_FALLBACK_SCSV with respect to intermittent failures situations will not be
very different from what it is with HTTP: the browser will show a failure page
and the user will hit the "retry" button.

So, it's not turning an intermittent failure into a permanent one: it's merely
turning an intermittent failure that may not have been visible to the user in
case a silent fallback into an intermittent failure visible to the user.

The only drawback is, as you note, the failure will be slower, compared to what
it would be without any fallback attempt. So the question is, which is worse:
1. Slowing down the display of an error message in case of intermittent failures
with a legitimate and compliant server (the situation with fallback and
TLS_FALLBACK_SCSV), or
2. Being unable to communicate with version-intolerant servers (the situation
without any fallback)?
(I leave out the 3rd option: being vulnerable to MITM downgrades, which I think
we all agree is bad.)

Manuel.