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 (Martin Rex) Tue, 20 January 2015 00:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ADA171A90D9 for <>; Mon, 19 Jan 2015 16:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_LOW=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 02Aj1gLkMrWJ for <>; Mon, 19 Jan 2015 16:59:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D362B1B2C03 for <>; Mon, 19 Jan 2015 16:59:16 -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 790AD3A223; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 471794211A; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
Received: by (Postfix, from userid 10159) id 3D1851B0FF; Tue, 20 Jan 2015 01:59:14 +0100 (CET)
In-Reply-To: <>
To: Brian Smith <>
Date: Tue, 20 Jan 2015 01:59:14 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
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: Tue, 20 Jan 2015 00:59:19 -0000

Brian Smith wrote:
> Martin Rex <> wrote:
>> Permitting the server to continue the TLS handshake with
>> ServerHello.server_version = (ClientHello.client_version +1)
>> This would be an extremely small change, but a *HUGE* improvement to this
>> proposal and make TLS handshakes _succeed_, i.e. promote interop.
> This doesn't work. Consider this example of how your suggestion would work:
> Client and server both support TLS 1.2.
> Client attempts TLS 1.2, receives RST.
> Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
> Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.
> This results in a downgrade from TLS 1.2 to TLS 1.1.

The improvement works *PERFECTLY* in your above example.

 - the server continues the handshake successfully
 - the client can clearly see from the server's response that the
   server recognized the FALLBACK_SCSV

It is then properly up to the client who asserted FALLBACK_SCSV
to consciously decide whether aborting the current handshake could
*really* provide a benefit, maybe even keeping the established session

In case the server, or client, or both, support only RC4 stream cipher 
and CBC cipher suites, the resulting TLS session with TLSv1.1
(the version that succeeds in your example) is comparable in strength
to one that would have succeeded with TLSv1.2.

The improvement is already better by a significant margin that the current
proposal if it makes *additional* TLS handshakes complete rather than fail
compared to the current proposal.  In your above example,

Now the part that you didn't say here:  if the cause of the RSTs wasn't
an attacker, but a dense middle-box, then the result would be a complete
interop failure -- and the only workaround (rather than the user removing
the "s" from the URL), would be for the client to
not send the FALLBACK_SCSV -- in which case the entire protection scheme
would fail.

> > Should a TLS client be unsatisfied with the properties of the resulting
> > TLS session, that client could still decide attempting a new/different
> > handshake by proposing additional features in ClientHello (that should
> > have never been absent from ClientHello in the first place).
> I think at this point browsers are only "satisfied" when the
> connection is TLS 1.2 using an AEAD cipher suite, but they still feel
> the need to support servers that only support worse crypto. So, this
> part of the idea doesn't work either.

Many servers do not even support AEAD cipher suites, including lots of
servers that support TLSv1.2.  And hundreds of millions of clients do
not support AEAD cipher suites either (think mobile).

Keep in mind that TLSv1.2 (rfc5246) contains not a single AEAD cipher
suite in the base specification, and the mandatory-to-implement cipher
suite in TLSv1.2 is TLS_RSA_WITH_AES_128_CBC_SHA.
Until _VERY_ recently (in a botched initial Hotfix delivery), Microsoft
did not support any AEAD cipher suites with RSA server certificates
on Windows 7 & 2008R2.

Random pick of a production Akamai server (TLSv1.2, but no AEAD):