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 <> Thu, 22 January 2015 10:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DC8A11AC410 for <>; Thu, 22 Jan 2015 02:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bwyvvj-JI_JD for <>; Thu, 22 Jan 2015 02:37:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C67F1A0AF8 for <>; Thu, 22 Jan 2015 02:37:35 -0800 (PST)
Received: from monty.local ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id t0MAxQ6s012872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 10:59:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=klaatu; t=1421924371; bh=tdW5ol8GxcIEH06MwxbBldSO1KVP1GAz5FIccjqf1hI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=GUjQmtM1+7qW8ei7hcsEusyQHufqHeN4iyCELHZufKF4n9sDP5ypRwO4YiMZm/aud QENP2e66/h3IjpZ/yaDEoPiiuiCOc5Z+DqKbZTiS4HiyL5T8P5HP9JrJwQJNNkdbSW dhoes5q//7vccBKjLfWsS9UpNE2xiZVaOjzYgOBs=
Message-ID: <>
Date: Thu, 22 Jan 2015 18:37:24 +0800
From: Michael Clark <>
Organization: Metaparadigm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <>
References: <> <, > <> <, > <> <BAY180-W688DE2930CB7F231E60989FF480@phx.gbl> <, <> <> > <BAY180-W1849690A1D8C42F1063DDBFF480@phx.gbl> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at
X-Virus-Status: Clean
Archived-At: <>
Cc: "" <>
Subject: 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
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jan 2015 10:37:37 -0000

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