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

Bodo Moeller <bmoeller@acm.org> Tue, 16 December 2014 08:57 UTC

Return-Path: <SRS0=hhoj=BE=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A21ACD42 for <tls@ietfa.amsl.com>; Tue, 16 Dec 2014 00:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mrmgbwv5WeC for <tls@ietfa.amsl.com>; Tue, 16 Dec 2014 00:57:43 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599F51A6FC0 for <tls@ietf.org>; Tue, 16 Dec 2014 00:57:43 -0800 (PST)
Received: from mail-ob0-f181.google.com ([209.85.214.181]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MXYso-1YTpZK39QU-00WZad for <tls@ietf.org>; Tue, 16 Dec 2014 09:57:41 +0100
Received: by mail-ob0-f181.google.com with SMTP id gq1so21982554obb.12 for <tls@ietf.org>; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.202.88.132 with SMTP id m126mr20270983oib.57.1418720259370; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Tue, 16 Dec 2014 00:57:39 -0800 (PST)
In-Reply-To: <20141215214116.159171B085@ld9781.wdf.sap.corp>
References: <20141215141627.11153.69398.idtracker@ietfa.amsl.com> <20141215214116.159171B085@ld9781.wdf.sap.corp>
Date: Tue, 16 Dec 2014 09:57:39 +0100
Message-ID: <CADMpkcKKyd9hUjDHief5o=Vu5SXzUSmWbROzMFz5gkn-UJ7qEQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
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;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q1OtlvFhpOSdfeiDDpViJn6xYyE
Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2014 08:58:32 -0000

Martin Rex <mrex@sap.com>;:

> http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03



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

Bodo