Re: [TLS] SCSVs and SSLv3 fallback

[Nikos Mavrogiannopoulos <[e-mail]>]

On 04/06/2013 12:11 AM, 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?


It may reduce the error failures in some middle-boxes. We cannot be sure
about that because we don't know the actual reason for failure, we just
speculate.

Nevertheless your focus on SSL 3.0 is also wrong. Given the number of
security flaws known to that protocol it may be more productive for the
WG to work towards phasing it out.

>> 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.


What would you do at the case a middle box only accepts extension A
using SCSV but extension B is only accepted as ClientHello extension?

Since what are you countering of is bugs, you can never be sure what the
next bug would be. Bugs should be treated as bugs.

> This idiom is so simple it could be handled by an "extender file"

The previous extension mechanism was even simpler but still there were
several middle-boxes that got it wrong.

regards,
Nikos