Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.txt)

Bodo Moeller <bmoeller@acm.org> Tue, 11 November 2014 15:52 UTC

Return-Path: <bmoeller@acm.org>
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 6FF001A8AB2 for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 07:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Level:
X-Spam-Status: No, score=-0.262 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_SOFTFAIL=0.665] 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 fiJPRNNEX_MG for <tls@ietfa.amsl.com>; Tue, 11 Nov 2014 07:52:25 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 0983D1A8AB0 for <tls@ietf.org>; Tue, 11 Nov 2014 07:52:25 -0800 (PST)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0Lfnn4-1YKlSf03uU-00pKrM; Tue, 11 Nov 2014 16:52:23 +0100
Received: by mail-ob0-f176.google.com with SMTP id va2so7527597obc.21 for <tls@ietf.org>; Tue, 11 Nov 2014 07:52:21 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.102.211 with SMTP id fq19mr34051115oeb.2.1415721141958; Tue, 11 Nov 2014 07:52:21 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Tue, 11 Nov 2014 07:52:21 -0800 (PST)
In-Reply-To: <546212B6.9020304@redhat.com>
References: <20141110200755.3975.81921.idtracker@ietfa.amsl.com> <546212B6.9020304@redhat.com>
Date: Tue, 11 Nov 2014 16:52:21 +0100
Message-ID: <CADMpkcJyQDNaNs+qLivFtsyea6iS5H5HmMUNt3zVKGE2Px=zjA@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e01160a2ec481bb050797434c"
X-Provags-ID: V02:K0:S+jhw5HdHqJAo1f3Yul0RHBTmUZfNG3N3Z3g/lF9Whe RPEPhvS8G61IoigTIER3BD4XSX7UBFu3GsO5Ygt12XRjbRS6Oe sFYc5uCgXh2pR6oKC8Nzb7/jxI+R9m05LGGjaQRpR0tGCBXOt4 9hVPoTZEjKN0FjCk41DpLwga0j3Wr2rBVPG96TJefZABjM9His yLMl5pYWQWXsrd9Bd0T25+v2ETopi/4OyQgaFxJ9tiG7+Nkvzg eHgjxvr86DaFOW9koVgiZ2uFAW97RDVEE5NhAa9cACUxsHqJEY 4/FH4FQYrMoNca4BPInNABnutsFYL28wjkhzmVDCcbGRCgvEe4 +M3cFfpgMejRFjNKk9/D54egqPv1y80/lzF1QFUd6rKPRfwdlc DXRlumeiYy45hxWmiUWeIEIjzDUjb4fO1C3Ec0zLQfwSQTTJMR rgldl
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l-DYx6KornAdm8ZwU1TbR84Hl_I
Cc: Florian Weimer <fweimer@redhat.com>
Subject: Re: [TLS] Protocol version for inappropriate_fallback alerts (was: Re: I-D Action: draft-ietf-tls-downgrade-scsv-01.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, 11 Nov 2014 15:52:26 -0000

Florian Weimer <fweimer@redhat.com>:


> Section 3 still does not mention which version to put into the
> inappropriate_fallback alert message.


Good point; it can't hurt to be completely explicit about this.

Proposed new wording:

o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the highest
protocol version supported by the server is higher than the version
indicated in ClientHello.client_version, the server MUST respond with a
fatal inappropriate_fallback alert *(unless it responds with a fatal
protocol_version alert because the version indicated in
ClientHello.client_version is unsupported). The record layer version number
MUST be set to ClientHello.cipher_suites for this alert (as it would for
the Server Hello message if the server was continuing the handshake)*.


Bodo