Re: [TLS] SCSVs and SSLv3 fallback

[Trevor Perrin <[e-mail]>]

Hi Hanno, Geoffrey, Yngve,

Thanks for the info and thoughts, really helpful!

It would get complicated to respond to every point individually, let
me try to summarize:


(1) I've heard anecdotal evidence that something like 1/1000
connections between TLS-capable (clients *and* servers) end up in an
SSLv3 fallback.  Hanno and Geoffrey point out this is often due to
general network problems (e.g. packet loss) rather than middlebox
TLS-intolerance.  However I have heard, and Yngve seems to agree, that
middlebox TLS-intolerance also contributes.

Does anyone know more about this?  Like: what portion of the above
fallbacks are due to general network problems vs. TLS-intolerant
middleboxes?


(2) I suggested that TLS Extensions which do not require data in the
ClientHello, and which are required for security, could follow the
5746 idiom of an SCSV alternative to the ClientHello extension for use
in SSLv3 fallback.

Geoffrey and Yngve suggest a different approach, where browsers
disable SSLv3 fallback when talking to a hostname for which they
expect one of these TLS Extensions.  With a flakey network, browsers
would retry TLS until they get through or give up.  With
TLS-intolerant middleboxes, Yngve suggests "standing firm and forcing
the problematic servers/infrastructure to be updated".

I see some problems with this:
 (a) With current proposals for CT or OCSP stapling, the requirement
for an OCSP or CT response via TLS Extensions is signalled by the
server's certificate, so is not known until *after* an SSLv3 fallback.
 Presumably the browser could cancel the SSL handshake and restart a
TLS handshake at that point, but that wastes multiple round trips.
 (b) With TLS-layer pinning (like TACK), this proposal would prevent
"active pins" from causing problems, but pin creation would still be
impeded:  Connections to not-yet-pinned sites could still suffer from
SSLv3 fallbacks due to flakey networks or intolerant middleboxes, and
not receive the pin assertion.
 (c) This proposal is guaranteed to fail with TLS-intolerant
middleboxes, whereas the SCSV proposal has a good chance of working.
 (d) As far as "standing firm" and trying to drive these middleboxes
off the Internet.  I'm all for someone else trying that (CT? :-).  But
for TACK:  If there's any significant number of these middleboxes, and
we cause anything close to a 1/1000 failure rate, we simply won't be
deployed.


I'd be interested in hearing more about why people oppose the SCSV
approach.  We're nowhere close to exhaustion of the ciphersuite (or
extension) registries.  Is there some real problem with SCSVs, or does
it just offend people's sense of the "proper way" to do things?


Trevor