Re: [TLS] An SCSV to stop TLS fallback.

[[e-mail] (Martin Rex)]

Daniel Kahn Gillmor wrote:
> On 12/06/2013 01:25 PM, Martin Rex wrote:
>>
>> So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
>> of the TLS protocol not at all, or cause a fatal handshake failure.
>> And very few, if any at all, of the situations where the handshake fails,
>> will be instances of an active attack.
> 
> This is probably also true of X.509 certificate validation failure as
> well, since there are more self-signed or expired certificates in active
> use than there are active MITM attackers.  Are you suggesting that TLS
> would be better off not checking certificate validity?

When both peers manage to signal to each other that they could
have done better, why moaning, failing and annoying the user,
when those peers could simply *USE* those better features instead.


> 
> > And it remains extremely
> > questionable, when the handshake would succeed, that the attacker
> > will gain anything at all.
> 
> What the attacker can gain presumably depends on what features the
> client is willing to sacrifice during fallback.  Presumably, the client
> gives up specific features of the newer versions: e.g. AEAD, when
> falling back below TLS 1.2, or possibly all TLS extensions for fallback
> all the way to SSLv3 (to accomodate old extension-intolerant SSLv3 servers).
> 
> It looks like you're saying that none of these more modern features are
> useful tools in defending against an active attacker.  Do you really
> think that?


I really think that trying to reduce the large scale of grey into
a binary black/white guess by the server about what the client
_might_ deem appropriate is doomed to fail.

If the client wants to make a conscious security trade-off decision
about what features it is willing to sacrifice to obtain interoperability,
then it is the _client_ which should perform the decision.  And in case
of a client operated by a human user (such as a web browser), that
trade-off might involve asking the user.

The server doesn't know anything about the client's motivation,
nothing about the actual request that the client is intending to
submit and nothing about the trade-off that the client would
be willing to perform (rather than fail).


Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
thing the client might be "loosing" is a little performance, and
that AEAD can not currently be negotiated and used unless
ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
of the specification(s) that could be easily fixed.

Btw. am I reading this page correctly:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx

Does Microsoft limit AES-GCM really to ECDHE_ECDSA on Win7 and Win8
i.e. unavailable with ECDHE_RSA ?


-Martin