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

[[e-mail] (Martin Rex)]

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.


With the current proposal, the server is supposed to abort the handshake,
but with pretty much no useful information to perform any kind of sensible
risk management, no means to cause the client to retry with "more features",
and not the slightest clue what "more features" really means.


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:
   - only the client knows *which* features it actually omitted
   - only the client knows how often it has tried to perform the handshake
     (how long he has been doing the "downgrade dance") on the current
     request.
   - only the client can decide to perform another request with 
     more/better options than what the server picked and returned in
     ServerHello
   - only the client can tell the user/admin about what happend
     (how often and how far it attempted to downgrade) and obtain
     a confirmation whether to continue/retry or abort.

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've been doing customer support for almost 20 years, I'm not just
doing software development and maintenance, and the type of support
that I do includes analyzing and explaining to customers interop failures
when trying to access TLS-protected resources and suggesting them how
to change their configuration in order to obtain interop.

Interop failures that end with a fatal SSL alert or silent connection
closure are a royal pain to analyze, which is why I will never consider
a specification as the current one (neither on the client, nor on
the server side).   Both, as IETF TLS WG and as software engineer(s),
we can do *MUCH* better easily.


-Martin