Re: [TLS] Cipher suite values to indicate TLS capability

[Chris Richardson <[e-mail]>]

(replying to the entire list this time...)

As a server, I could:
1: Support TLSv1 and SSLv3, and not support the SCSV
2: Support TLSv1 and SSLv3, and support the SCSV
3: Support TLSv1 but not SSLv3, and the SCSV is irrelevant.

With (1), I'm willing to support SSLv3 for anyone.
With (2), I'm wiling to support SSLv3, but only for clients who aren't
TLSv1 capable.
With (3), I'm unwilling to support SSLv3 for anyone.

Behind the SCSV is the suggestion is that SSLv3 should be considered
harmful.  If SSLv3 is harmful, then why only reject it for
TLSv1-capable clients?  Why not reject it for everyone?

(One benefit of the SCSV that I can see is that a downgrade-to-SSLv3
attack can be detected, which would be an indication that SSLv3 should
be considered harmful, even if we don't know why.)

On Wed, Jun 6, 2012 at 1:17 AM, Yoav Nir <[e-mail]> wrote:
>
> On Jun 6, 2012, at 4:11 AM, Chris Richardson wrote:
>
>> On Tue, Jun 5, 2012 at 4:39 PM, Adam Langley <[e-mail]> wrote:
>>> However, with the downgrade to SSLv3 we loose an important security
>>> feature: ECDHE.
>> ...
>>> So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3
>>> handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can
>>> deploy new ciphersuites for SSLv3 and the semantics of
>>> TLS_CAPABLE_SCSV would be that servers would reject any SSLv3
>>> handshakes that included this ciphersuite with a fatal error.
>>
>> Thinking through various scenarios... if I'm a TLS-capable server that
>> does not support foward-secure cipher suites, what reason would I have
>> any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV?
>
> Because the client says it supports TLS, but is connecting using SSLv3. That is evidence of a downgrade attack. Regardless of what benefit the attacker intends to get from downgrading the connection to SSLv3, it should be aborted.