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

[Dave Garrett <[e-mail]>]

On Thursday, January 22, 2015 03:40:35 am 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.
[...]
> The core issue is Appendix E does not make explicit a protocol version
> deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
> lower bound of { 3, 1 } for the record layer TLS version in the
> ClientHello as they are the same major version (in reality).
> The fact that SSLv3.0 has partial record layer binary compatibility
> is a red herring. We should notionally subtract { 2, 1 }.
> SSLv3.0 is past the used by date.

I have PRs to deal with this area in TLS 1.3 still pending a decision. The 
current version is the consensus from the previous discussion on the topic.

https://github.com/tlswg/tls13-spec/pull/105
https://github.com/tlswg/tls13-spec/pull/107

The changes are to prohibit SSL negotiation, drop SSL2 hello format 
documentation, freeze record layer hello version to 3.1, as well as other 
editorial improvements.

I haven't heard back from ekr in a couple weeks.


Dave