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 5:40 pm, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-22 at 16:40 +0800, Michael Clark wrote:
> 
>> = TLSv1.3 implementations could remove SSLv3.0 support such that
>>   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
>>   instead of { 3, 0 } which is mentioned in the Appendix as a
>>   "typical value" and the maximum "message layer" version a server
>>   accepts is specified as { 3, XX }. A TLSv1.2 client could send
>>   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
>>   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
>>   with protocol major/minor best practices for binary changes and
>>   backwards compatibility. i.e. no binary incompatible changes in minor
>>   versions. Just raise non-compliance with Appendix E.1 as a bug.
>> [...]
>> = ClientHello Record Layer TLS version intolerance; strict lower bound
>>   for the *record layer* TLS "minor" protocol version) is protective.
>>   Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
>>   (from an evolutionary perspective).
> 
> These recommendations are plainly wrong, and worse, they harm
> interoperability for no security benefit. Unfortunately for some reason
> they somehow got implemented.
> 
> 1. The version in the record layer, _DOES NOT_ indicate the minimum
> version the client supports. It does indicate the format of the record
> packet. Having SSL 3.0 is perfectly valid, since the packet format
> remained the same.

The spec has wording that alludes to this. In my read.

> 2. Using it as an indicator of the client's minimum version is wrong as
> this field is not protected by the handshake hashes, so it shouldn't
> affect any of the decisions taken as part of the handshake.


This I was not aware of. That is a hole I can now see (in my reasoning
with respect to handshake tampering). Thanks for pointing this out.

I was under the impression that verify data protects the handshake.

Thanks. This should be addressed.

> 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.

Thanks.