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

On Mon, Nov 25, 2013 at 6:19 PM, Martin Rex <mrex@sap.com> wrote:
> Adam Langley wrote:
>> Sad as it is, in order to work on public Internet all browsers
>> implement TLS fallback: in the event of a handshake failure they will
>> retry the connection with a lesser SSL/TLS version.
>>
>> This means that an active attacker can disable AES-GCM support and,
>> ultimately, ECDHE if they push the browser back to SSLv3. It would be
>> good to finally do something about this.
>>
>> Thus I'd like to propose the design of an SCSV with which we can move forward:
>>
>>   In the event that a client is making a fallback connection, it
>> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>> current server which sees this cipher suite in a ClientHello SHOULD
>> return a fatal alert, inappropriate_fallback (86) and abort the
>> connection.
>
>
> We keep this proposals for newly creating interop problems keep
> coming up on this list?
Why didn't you complain before we had the problems?
How does AGL's proposal introduce interop issues?
I agree this is important to avoid in the future, but I don't think
this proposal
causes any more problems.
>
> How about instead fixing the negotiation so that AES-GCM&AES-CCM
> can be sent in whatever ClientHello there is (including SSLv2)
> and an additional SCSV to signal availability of a specific subset of
> ECDHE that can be used without a TLS ECC extension, such as the subset
> that is supported by Windows 7+?
SSLv2.0 is irredeemably broken.
SSLv3.0 doesn't use HMAC, so the decision was made to go to TLS 1.0, rather than
negotiate an extension. It also only supports SHA1 and MD5. The
allowable key exchanges
also changed. Implementing this in a backwards-compatible manner would be hard.
Why the SSL structure was kept around is beyond me: surely someone in
1999 should have
understood the cryptographic issues inherent in the design. (Actually
someone did, namely Rogaway, and everyone ignored him).
But yes, to the extent we can make future changes backwards compatible
we should.
>
>
> If there is a problem in negotiating what _we_want_to_do_, because the
> installed base does not like the kind of negotiation that was originally
> proposed to be used, then the pragmatic engineering approach will be
> to define an alternative negotiation of at least a useful subset
> that will be compatible with the installed base, and which will not need
> to be stripped from a "conservative fallback handshake" -- and therefore
> will be resilient to downgrade attacks, and cope with retarded middle boxes.
>
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin