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

[Michael Clark <[e-mail]>]

On 22/1/15 6:11 pm, Michael Clark wrote:
> On 22/1/15 5:40 pm, Nikos Mavrogiannopoulos wrote:
>> 3. Forbidding SSL 3.0 version from the record layer breaks perfectly
>> valid clients, which advertise TLS 1.2. These clients can only use a
>> variant of fallback dance to connect to broken servers which impose
>> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.
> 
> OK. Then an extension to indicate supported versions would in fact be an
> improvement as it would be protected by verify_data.
> 
> I'm not in supported of downgrade dancing. I was completely unaware that
> the entire handshake is not hashed.

I guess this is the crux of the matter. I was trying to figure this out
from the spec. A future version needs to state that *all* handshake data
is authenticated. My original suspicion.

My read of the stats was that < TLS1.0 { 3, 1 } represents 1.6%

Clearly the version *range* indication as per Appendix E.1 i.e. the
actual point of my mail, should be hashed as it does then allow for
handshake tampering. I made a note of my *false* assumption, that
the handshake is hashed (and required pre-image).

The spec does say:

 TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

SSLv3.0 is advised against everywhere. I guess it's living with a wart
of using a record protocol version that you don't support given the
minimum most are willing to negotiate these days is TLSv1.0 { 3, 1 }.

Anyway that fact that the handshake is *not* completely hashed is
perhaps the most important issue to address given there is no secure
way to indicate a range of supported versions. i.e. SSLv3.0 deprecation.

If { 3, 0 } has to be the record protocol version in an unauthenticated
layer then so be it. It only gives more weight to the need for a
mechanism to indicate "Supported Versions" in an extension that is part
of the hash. i.e. the Thought Experiment that I discounted based on the
false assumption of the forgery proof of handshake messages.

Clearly TLS needs to authenticate the *whole* handshake and signal
minimum version securely and have no fallback to insecure versions if
this minimum version can be tampered with. Clearly the minimum version
needs to be in the verify_data hash (somehow as an extension).

TLS 1.0 should be a minimum. People need to upgrade. You can't keep
backwards compatibility and security at the same time when SSLv3.0
is insecure.