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

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:

> Bodo Moeller wrote:
>


> > Continuing the handshake would not require any app-level changes to
> Servers
> > > that have not been writing fatal SSL alerts to the network before
> > > connection closure in the past, such as Microsoft IIS, so clients
> > > with fallback heuristics will be in a *MUCH* better position to
> > > recognize and distinguish accidental network glitches or connection
> > > management bugs from attacks.  I expect the false positives to
> > > outnumber attacks by at least three orders of magnitudes.
>


> > If there's an *actual* attack and the client doesn't continue with the
> > connection, the attacker can suppress alert details anyway. The alert (if
> > it gets through) is useful for heuristics; the only definitive protection
> > is from making sure that the client and server won't exchange application
> > data.
>


> I believe we're still talking past each other.
>
> It will be impossible to protect the handshakes between two TLS peers
> where one of them does not know about the FALLBACK_SCSV.
>
> We're discussing purely the situation where _both_ sides are patched.
>

Right. I was commenting on your remark about distinguishing non-attacks
from attacks: this is never reliably possible, because the attacker could
make its behavior look like network glitches.



> If instead, the server includes a ServerHelloExtension when recognizing
> the Fallback SCSV, then the client will have *MUCH* better information
> available to make sensible risk management:

[...]

> It's up to you / the WG to decide what the contents / semantics of
> such a ServerHelloExtension should be, i.e. whether the presence
> of the extension is a simple Boolean with a meaning closer to
> the currently suggested fatal alert (i.e. an encouragement for the
> client to abort and reconnect), or whether there should be a more
> fine grained response, such as a structure that conveys the highest
> protocol version of the server, whether the TLS server understands
> and would appreciate TLS extensions or even a list of TLS extensions
> that the server would _really_ like to see (such as ECC, SNI, ...)
> or whether the server would really appreciate being offered
> a larger variety of TLS cipher suites.
>

I think this would amount to over-engineering (and due to that,
unnecessarily delaying) the fix.

With a well-functioning (version-tolerant!) server, there won't be fallback
retries, except those caused by network glitches. For those, having the
(necessarily unauthenticated) network glitch eventually result in an (also
unauthenticated) fatal inappropriate_fallback alert shouldn't be
problematic. Continuing with the handshake to authenticate a
ServerHelloExtension that tells you more about the problem will make both
parties spend more time and computational effort before they abort the
connection, with little gain.

Bodo