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

[Tom Ritter <[e-mail]>]

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?

If there's a practical way to detect an attacker trying to downgrade
you, that doesn't shred the protocol, I think it's pretty useful.
SCSV's are ugly and a slippery slope, but when someone in an accurate
position tells you "We're going to have the fallback behavior for a
long time" one or two more to gain the advantage of these new
protocols looks pretty good.  (The other approach being taken is
drawing a little enclave and saying "In this zone, we will hard fail,
and if your software can't handle TLS1.0 or DNSSEC, people can't
connect to you.", but that's not really applicable here.)

On 6 June 2012 03:12, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> 2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0
> should have been disabled.

I would say it was a user who wanted to use the more secure version of
the protocol available, and not be downgraded by an attacker.

On 6 June 2012 03:25, Geoffrey Keating <[e-mail]> wrote:
> I think the whole fallback thing is terrible, and I don't agree with
> it at all.  But if we must do it, then this makes it slightly better,
> and does so without standardizing bad practice.  (I think it also
> works with many existing hosts, therefore making the deployment
> problem significantly simpler.)

Reusing a ECDHE ciphersuite is standardizing less of a bad practice,
but it's more un-intuitive. Does ECDHE indicate support of ECDHE or
TLS 1.0?  (An AES-GCM ciphersuite would conclusively indicate TLS 1.2
- until we have TLS 1.3)



Would it make sense to define all three: TLS_1_{0,1,2}_CAPABLE_SCSV
and send only the highest one from the client?  I think if people are
adding in the code to handle the SCSV, the code could be written in a
sturdy and reusable way such that adding a fourth later on wouldn't
even require a code change, just another item to an array.

-tom