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

[Nikos Mavrogiannopoulos <[e-mail]>]

On 06/08/2012 01:23 AM, Tom Ritter wrote:

> On 7 June 2012 18:34, Chris Richardson <[e-mail]> wrote:
>> 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.)
> 
> This proposal, and a few others being worked on in various places, aim
> to address the problem we have with hard fail and backwards
> capability. In some scenarios TLSv1, DNSSEC, DANE, etc all fail not
> because someone is performing an attack, but because some piece of
> software can't handle some portion of the secure protocol.  And
> because Operating Systems and Browsers have an incentive to make
> things work for their users, they retry will less, or no, security.
> Attackers can exploit this mechanism to get the advantages of the
> lesser form (less or no security).
> If we don't move the line in the sand forward, if we don't make a
> decision that says "We will support this buggy or incomplete software
> no more", there's no point in defining new security protocols.  What's
> the point in DNSSEC if it only is used when someone's not attacking
> you?  What's the point in TLSv1, 1.1, or 1.2 if the security gains
> (correct IV, DHE, AEAD, SHA256) will never be realized when there's an
> attacker there?


I don't quite get the point. If the goal of the attacker is to perform
denial of service on the secure protocol so that the user uses the
insecure protocol (plaintext), how does this approach help? It doesn't.

If you want to only prevent against the attacker that wants to rollback
the session to SSL 3.0, then all you need to do is to perform the proper
TLS protocol negotiation, which protects against that. If it doesn't
work warn the user.

In reality however, there is the fact that several buggy servers do not
implement the TLS protocol but rather a wrong variant of it, that fails
performing the fallback.

To account for that issue several browsers perform non-standard TLS
version fallback in a way that is not protected by the handshake.
Hacking the protocol to understand and detect this non-standard fallback
will create another protocol in par with the TLS protocol, which we have
no guarantees that will be better implemented than the original protocol.

What happens if we have a buggy server that incorrectly implements the
fallback detection mechanism? We define another one?

If the problem is incorrect implementations, then just fix the incorrect
implementations. If you cannot, then do not interoperate with them. If
all major browsers do that, the owners would fix it.

My point is that TLS is already complex. Making it more complex will not
make it easier to implement it, but harder, and it will introduce more
points of failure and interoperability rather than less.

regards,
Nikos