Re: [TLS] SCSVs and SSLv3 fallback

[Trevor Perrin <[e-mail]>]

On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> On 04/05/2013 09:46 PM, Trevor Perrin wrote:
>
>
>>  (c) This proposal is guaranteed to fail with TLS-intolerant
>> middleboxes, whereas the SCSV proposal has a good chance of working.
>
> [...]
>> 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?
>
> I wouldn't expect the problem of failed TLS connections due to middle
> boxes or bad implementations to disappear by making a complex protocol
> even more complex.

If the problem is TLS-intolerant middleboxes, then allowing necessary
handshake data to flow via SSLv3, using a mechanism that has worked
for other extension data, should make the problem better.  No?


> By having a protocol that offers more than a way to do things I'd expect
> an increase to the interoperability and failed connection issues we see
> today. More options for the same thing pretty much guarantees that there
> will be at least one implementation that will ship the non mainstream
> options untested.

This is pretty easy to test, the logic is simple:
 - client sends SCSV and/or empty ClientHello extension
 - on receiving SCSV and/or empty ClientHello extension, server sends
ServerHello extension.

This is even simpler than RFC5746, since for (CT, TACK, OCSP
"must-staple") the ClientHello Extension could just be an empty
signal, and the ServerHello contains a static response.

This idiom is so simple it could be handled by an "extender file"
interface:  The site administrator could specify an "extender file"
containing PEM-encoded TLS Extensions in the server config.  Each
PEM-encoded blob would contain a prefix specifying the TLS extension
number and (optional) SCSV number.  This would avoid the need for
server-side code changes for any Extension that follows this idiom.

So, we would only need to deploy this once into (OpenSSL, Apache,
nginx, etc.).  Does that alleviate your concern?

I've discussed this with Ben Laurie and begun an OpenSSL patch, which
at least CT and TACK could take advantage of.  It doesn't allow SCSV
specification yet, but I'm wondering if it should:

https://github.com/trevp/openssl_extender


Trevor