Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt

Bodo Moeller <> Tue, 16 December 2014 08:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A2A21ACD42 for <>; Tue, 16 Dec 2014 00:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Mrmgbwv5WeC for <>; Tue, 16 Dec 2014 00:57:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 599F51A6FC0 for <>; Tue, 16 Dec 2014 00:57:43 -0800 (PST)
Received: from ([]) by (mreue102) with ESMTPSA (Nemesis) id 0MXYso-1YTpZK39QU-00WZad for <>; Tue, 16 Dec 2014 09:57:41 +0100
Received: by with SMTP id gq1so21982554obb.12 for <>; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id m126mr20270983oib.57.1418720259370; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
Received: by with HTTP; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 16 Dec 2014 09:57:39 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary="001a113d550c1878d1050a518db7"
X-Provags-ID: V03:K0:rrvCihGgDjiwQxB35ZJ1EQ3/jG5aXrwlhsh+HxR2klaxtuzOzwO XI+8P3yRXrGul1l1S0r4BPiFinVw2OuCWPwF/mIplzpUi9zhHyiEjBopXouxKuILUQe9uHt dwQH2KNxKvCsaKvsYfaG+2nWwLT9rpQB7mxSpbQHYyJmNCLNjpSfJM2qo/Xf5HzS/pgVrU6 7G+05YDm+tGNMCbW0Z20Q==
X-UI-Out-Filterresults: notjunk:1;
Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt
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, 16 Dec 2014 08:58:32 -0000

Martin Rex <>:


> The current document seems still silent on the *KNOWN* problem when
> a client App has been skipping TLS versions on downgrade dance.

> MSIE 8 seems to be a browser that skips versions on downgrade dance.
> MSIE 8 on Win7 with TLSv1.2 enabled, dances like this:
>    TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext)

To recap what's been previously said, I don't think that a change to the
I-D is warranted.

- The (obvious) way to make this work is to not skip versions in the
downgrade dance. Often the downgrade will be happening because of a flaky
network, not because it is required with a specific server (or induced by
an active attacker): in that case, if the server does not recognize
TLS_FALLBACK_SCSV, it is more appropriate and generally better for security
to fall back to TLS 1.1 rather than to TLS 1.0.

- I do realize that some implementors may prioritize latency improvements
over the security gain here and hence may still prefer to skip TLS 1.1. I
won't encourage that behavior, but draft-ietf-tls-downgrade-scsv-03 doesn't
disallow it. In practice, the above sequence (after TLS 1.2, attempt TLS
1.0 with TLS_FALLBACK_SCSV) should generally work well enough because
support for TLS_FALLBACK_SCSV in servers with a maximum protocol version of
TLS 1.1 will probably remain rare. To maximize interoperability, such
clients should attempt TLS 1.1 with TLS_FALLBACK_SCSV later in the
downgrade sequence (i.e., after TLS 1.0 with TLS_FALLBACK_SCSV).