Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Brian Smith wrote:
> Martin Rex <[e-mail]> wrote:
>> Permitting the server to continue the TLS handshake with
>> ServerHello.server_version = (ClientHello.client_version +1)
>>
>> This would be an extremely small change, but a *HUGE* improvement to this
>> proposal and make TLS handshakes _succeed_, i.e. promote interop.
> 
> This doesn't work. Consider this example of how your suggestion would work:
> 
> Client and server both support TLS 1.2.
> 
> Client attempts TLS 1.2, receives RST.
> Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
> Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.
> 
> This results in a downgrade from TLS 1.2 to TLS 1.1.


The improvement works *PERFECTLY* in your above example.

 - the server continues the handshake successfully
 - the client can clearly see from the server's response that the
   server recognized the FALLBACK_SCSV

It is then properly up to the client who asserted FALLBACK_SCSV
to consciously decide whether aborting the current handshake could
*really* provide a benefit, maybe even keeping the established session
around.

In case the server, or client, or both, support only RC4 stream cipher 
and CBC cipher suites, the resulting TLS session with TLSv1.1
(the version that succeeds in your example) is comparable in strength
to one that would have succeeded with TLSv1.2.


The improvement is already better by a significant margin that the current
proposal if it makes *additional* TLS handshakes complete rather than fail
compared to the current proposal.  In your above example,


Now the part that you didn't say here:  if the cause of the RSTs wasn't
an attacker, but a dense middle-box, then the result would be a complete
interop failure -- and the only workaround (rather than the user removing
the "s" from the https://some.host/ URL), would be for the client to
not send the FALLBACK_SCSV -- in which case the entire protection scheme
would fail.




> 
> > Should a TLS client be unsatisfied with the properties of the resulting
> > TLS session, that client could still decide attempting a new/different
> > handshake by proposing additional features in ClientHello (that should
> > have never been absent from ClientHello in the first place).
> 
> I think at this point browsers are only "satisfied" when the
> connection is TLS 1.2 using an AEAD cipher suite, but they still feel
> the need to support servers that only support worse crypto. So, this
> part of the idea doesn't work either.


Many servers do not even support AEAD cipher suites, including lots of
servers that support TLSv1.2.  And hundreds of millions of clients do
not support AEAD cipher suites either (think mobile).

Keep in mind that TLSv1.2 (rfc5246) contains not a single AEAD cipher
suite in the base specification, and the mandatory-to-implement cipher
suite in TLSv1.2 is TLS_RSA_WITH_AES_128_CBC_SHA.
Until _VERY_ recently (in a botched initial Hotfix delivery), Microsoft
did not support any AEAD cipher suites with RSA server certificates
on Windows 7 & 2008R2.

Random pick of a production Akamai server (TLSv1.2, but no AEAD):
https://www.ssllabs.com/ssltest/analyze.html?d=www.microsoft.com&s=23.203.223.109


-Martin