Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Correct, but I'm more concerned about this scenario: suppose a client implements a three-stage fallback: TLS1.2-with-extensions ---> TLS1.0-with-extensions ---> SSLv3.
Suppose TLS1.2-with-extensions got a RST from a TLS1.2-supporting server because there is an interoperability problem, or a middle box problem, or a configuration problem, etc.
The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, the handshake may have succeeded, but with SCSV the TLS connection will fail.

>From the standpoint of the browser vendors, this largely defeats the purpose of re-connects. Perhaps a browser could only send the SCSV on the last re-connect, when downgraded to the least secure protocol version (e.g. SSL3). But even this compromise seems unlikely to get deployed.

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com] 
Sent: Tuesday, January 28, 2014 7:58 AM
To: Andrei Popov
Cc: Adam Langley; tls@ietf.org
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Well, suppose a client implements a three-stage fallback: TLS1.2-with-extensions--->TLS1.0-with-extensions--->SSLv3.

Suppose TLS1.2-with-extensions got a RST. The client is now trying TLS1.0-with-extensions. If it gets an alert, it will know that it needs to stop. If it gets another RST, it will proceed to try SSLv3, and that's a bad thing, because it should have stopped at TLS 1.0.

I don't think it matters much, because if an attacker can cause a TLS 1.2 session to fail, it can do the same to a TLS 1.0 session. So an attacker can always force the sides to the lowest common denominator. The best this extension can do is to make sure that when they finally do talk to each other at the lowest common denominator, that they recognize that the interference had happened. As long as they don't go below SSLv3, they will know that with the SCSV, regardless of whether the server resets or sends an appropriate alert.

Yoav

On Jan 28, 2014, at 5:41 PM, Andrei Popov <Andrei.Popov@microsoft.com>
 wrote:

> Yes, this makes sense, and the other fatal TLS alerts are defined for similar reasons. Because of Martin's comment, I thought I might be overlooking a security issue with not sending inappropriate_fallback.
> 
> Thanks,
> 
> Andrei
> 
> ________________________________________
> From: Adam Langley <agl@google.com>
> Sent: Monday, January 27, 2014 5:52 PM
> To: Andrei Popov
> Cc: mrex@sap.com; Bodo Moeller; tls@ietf.org
> Subject: Re: [TLS] Call for acceptance of 
> draft-moeller-tls-downgrade-scsv
> 
> On Mon, Jan 27, 2014 at 8:04 PM, Andrei Popov 
> <Andrei.Popov@microsoft.com> wrote:
>> For my understanding: why is this proposal vitally dependent on the server sending inappropriate_fallback alert? If the server receives the SCSV, has a higher protocol version enabled than that in the ClientHello, and quietly aborts the handshake, isn't the downgrade attack thwarted?
> 
> Yes, just closing the connection is good enough for security. The 
> advantage of returning the fatal alert is that a) it stops the 
> fallback process faster and b) the client can report the error that 
> caused the original connection to fail, rather than that the final 
> fallback hit connection closed.
> 
> 
> Cheers
> 
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> Email secured by Check Point