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

[Henrik Grubbström <[e-mail]>]

On Fri, Jan 23, 2015 at 3:33 AM, Michael Clark <[e-mail]> wrote:
> On 23/1/15 12:59 am, Bodo Moeller wrote:
>
> Michael Clark <[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
[...]
> 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.

I don't see a need for this. The current SCSV in the draft seems
sufficient; it indicates to the server that the client believes that
there's some sort of problem with the connection, which not
necessarily is due to the protocol version, but that the client has
downgraded in an attempt to workaround.

Your approach risks cementing the misinterpretation of the record
layer version as the minimum protocol version, which is the cause of
many of the version-related problems.

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

Why mess with the version negotiation? The current protocol works fine
if the parties actually implement the RFCs.

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

See above.

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

This makes some sense.

>     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 seems stupid. There are three pieces of extra information
contained at the packet level in this case:

  * The packet content type

     This is handshake for all packets in the handshake (now that CCS
is gone in TLS 1.3), and thus contains no information.

  * The packet fragmentation.

    This is not relevant, since all payloads are concatenated before
the protocol actually looks at them.

  * The packet version number.

    This is not relevant, as either the version is 3.x in all packets
and the packets are accepted, or the version is something else and the
connection will be terminated.

/grubba

-- 
Henrik Grubbström                                       [e-mail]
Roxen Internet Software AB                              [e-mail]