Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

[Hubert Kario <[e-mail]>]

----- Original Message -----
> From: "Florian Weimer" <[e-mail]>
> To: "Rich Salz" <[e-mail]>, "Manuel Pégourié-Gonnard" <[e-mail]>, "Martin Thomson"
> <[e-mail]>, "Bodo Moeller" <[e-mail]>
> Cc: [e-mail]
> Sent: Friday, 17 October, 2014 11:23:17 AM
> Subject: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for
> draft-ietf-tls-downgrade-scsv-00)
> 
> On 10/16/2014 03:44 PM, Salz, Rich wrote:
> >> A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV
> >> unconditionally.
> >
> > A widely deployed client might also start injecting line noise into the TLS
> > stream.
> >
> > We can't control what buggy clients do.  That's not new.
> 
> You recently wrote about SSL_MODE_SEND_FALLBACK_SCSV, without any
> qualifications:
> 
> “I recommend that you always set that flag.”
> 
> <http://article.gmane.org/gmane.comp.encryption.openssl.user/52991>
> 
> Unfortunately, you are not the only one who makes this mistake.
> 
> I'm now convinced that the scenario I described is extremely likely.
> The problem, of course, is that you will not notice this bug in the
> client application until the server supports TLS 1.3, when it may be too
> late to fix it in the client.
> 
> It would be better to say that connections with TLS_FALLBACK_SCSV need
> to fail unconditionally in the server, independent of client and server
> protocol version.  This approach would essentially be a promise of the
> server to be version-tolerant (or a statement of having been updated
> recently, which hopefully amounts to the same thing).

But how can you test that the server really *is* tolerant to future
yet undefined protocol versions?

Sure, you can test if the code will accept a client hello with high
minor/major versions, but future versions may modify the initial hello
message in a way the programmers of the server didn't expect and that
actually crashes or generates a fatal error in the server (e.g. because
the server tries to parse whole hello message before looking at the
tls version).

Then to interoperate with such a server a browser would have to try
a client hello with lower version and without the SCSV to interoperate.
And we're in square zero...

>  The advantage
> that it doesn't come with the time bomb that has been built into the
> current draft.

While this is a possibility, I think the only thing we can do to prevent
that is to be explicit in the document:

"The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
with the highest protocol version it supports."

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [e-mail]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic