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 23/1/15 12:59 am, Bodo Moeller wrote:
> Michael Clark <[e-mail]
> <mailto:[e-mail]>>:
>  
>
>     + SCSV served a purpose of a mitigation while clients downgraded
>       due to version upgrade intolerant servers. It may have served its
>       purpose. Don't downgrade and there is no attack vector
>
>
> This is certainly true, but note that all the major browsers
> (including the current release of Mozilla Firefox) still *do*
> downgrade. Firefox has plans to disable the downgrade dance by
> default, but there'll still be a user setting for this, and various
> users may (have to) set this.  Not downgrading isn't entirely science
> fiction any more, but it ain't over until the fat lady sings.
>
> Not having to do downgrade retries is the right goal, but when we have
> achieved that, having the SCSV logic dormant in servers is really a
> minor low-complexity addition to the protocol that won't do any harm,
> and may (or may not) turn out to be useful again in the future.

I agree with you. Ideally a standards track draft should not codify a
workaround. People make mistakes. I'm not suggesting SCSV is a mistake.
It appears to be a workaround. We're humans.

If we have the ears (or eyes) of the standards group then I think
working towards downgrade avoidance and adding an extension to indicate
acceptable versions is a cleaner long term solution. If a server replies
with the version it uses on the record layer in an extension and we know
this is signed in verify_data then this serves an almost equivalent
purpose of SCSV but is much more explicit and offers a deprecation
mechanism that will be useful in the future. IMHO a cleaner mitigation.
Sure I understand the context that mitigation often needs to be deployed
in a hurry so I am sure everyone has consideration of that.

However this is my thinking, which was modified by the comments of others.

A).

    1). Codify use of a "Supported TLS Versions Extension" with either a
strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate SSLv3.0
        * Advisory to recommend the record layer ClientHello version be
fixed to the lower bound { 3, 0 } ; which there seems to be some
consensus for
        * In the case where the extension is echoed. i.e. supported, the
record layer version is echoed by the server and signed in the handshake.
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance. i.e. All TLS implementations can benefit from it.

And in TLSv1.3, where payload can be changed, and extensions can be
mandated, without breaking backwards compatibility, it also makes sense to:

B).

    1). MUST Codify use of a "Supported TLS Versions Extension" with
either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1 }
to deprecate SSLv3.0
        * In the case where the extension is echoed. i.e. the lower
bound is signed in the handshake.
        * This provides administrators with a clear indication of
supported versions and the ability to set their lower bound
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.
        * Complete deprecation of SSLv3.0 would like be achieved by the
time TLSv1.3 is in the wild.

    2). MUST tighten the wording with respect to the ClientHello record
layer and message layer versions
        * Fix the record layer ClientHello version to the lower bound {
3, 0 } ; which there seems to be some consensus for
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.

    3). MUST Extend the TLSv1.3 verify_data size from 12 octets to >=16
octets
        * In the TLSv1.3 time frame we are approaching a point where (
handshakes * ( 2^12) / ( 2^96 ) ) becomes a potentially exploitable weakness
        * The wording that defers to the cipher suite for
verify_data_length should be changed.

    4). MUST Include the entire handshake record layer rather than
content in the veryify_data hash
        * While this is a duplication of the mitigation in A.1, it is in
fact the real fix and the "Supported TLS Versions Extension" becomes an
indicator
        * "Supported TLS Versions Extension" would echoed to indicate
the lower bound and { 3, 0 } would be fixed at record layer.
        * Reasoning: The fact a mitigation is deployed (for backwards
compatibility) should not prevent the standard from deploying the real fix.
        * TLSv1.3 has an opportunity to change content layer semantics
of the handshake hash without breaking backwards compatibility
        * It needs to be tight { 3, 1} lower bound via extension and at
the same time loose { 3, 0 } in record layer for inclusive backwards and
forwards compatibility.

This is my analysis (plastic based on new information discovery); and I
realize my MUSTs may be different from the standards track or chair.

I still need to read the handshake hash code in one of the open
implementations. i.e. to prove at least to myself the core issue is
Hash(handshake_messages) vs Hash(handshake_records).

I read Hash(handshake_messages) which is a little ambiguous or a little
mistake. We're all human.

Below is a work in progress patch for 3). and 4).

Cheers,
Michael.

--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -2674,7 +2674,7 @@ Structure of this message:
 
 
 verify_data
-:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
+:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
              [0..verify_data_length-1];
 
 finished_label
@@ -2691,7 +2691,7 @@ Finished computation.
 > In previous versions of TLS, the verify_data was always 12 octets long. In
 the current version of TLS, it depends on the cipher suite. Any cipher suite
 which does not explicitly specify verify_data_length has a verify_data_length
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future cipher
 suites MAY specify other lengths but such length MUST be at least 12 bytes.