Re: [TLS] Fallback SCSV summary
Bodo Moeller <bmoeller@acm.org> Mon, 10 November 2014 20:02 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 87A811AC3E3 for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 12:02: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 Vn9D0U8lBfX8 for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 12:02:23 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (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 2413A1A90CC for <tls@ietf.org>; Mon, 10 Nov 2014 12:01:26 -0800 (PST)
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M3uUc-1Y6HHV3iPS-00raNy; Mon, 10 Nov 2014 21:01:24 +0100
Received: by mail-oi0-f53.google.com with SMTP id a141so5908768oig.40 for <tls@ietf.org>; Mon, 10 Nov 2014 12:01:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.102.211 with SMTP id fq19mr29226432oeb.2.1415649682508; Mon, 10 Nov 2014 12:01:22 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 12:01:22 -0800 (PST)
In-Reply-To: <CAOgPGoDr-UyBHpY3TMfPA8b_b3Brtpj3iYRt7a86ZNR8LunfuA@mail.gmail.com>
References: <CAOgPGoDr-UyBHpY3TMfPA8b_b3Brtpj3iYRt7a86ZNR8LunfuA@mail.gmail.com>
Date: Mon, 10 Nov 2014 21:01:22 +0100
Message-ID: <CADMpkcKzQd8M0syhnp2z2gU3Y3dDHZSkO0QptvrzfttVAPwr9w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e01160a2e73d495050786a0c4"
X-Provags-ID: V02:K0:Dps7oU+SGTrllpPCTrjSh5X5fa2tP0XQz5/gKw9BByg fI42A81BlT7WOU6ekQ/n2u9u3BZGDW19ModsydQWzRcUpSAPwj YstJW0m/eSL8rnrpYDBSL6ZmjZWUB79qtY2ErAOKV6SaC57PEN AkoLMj4k6/Cb8RAicd4FNapWQS4I1p21jlFlyD3/Kwe0PWIHCk 49GjJa4lbh86wgF8pFvYi8hx36KYgfk0RGQ9frem/v2Nv8Qu+s HIeW8lXbCFtZ2dWnKaGRcA1eT9YcNtjS9SpPuNxP7MB2U0DI+4 0NCIM4WjseE0GN4UisLtU86bX3um7+gGRPE27/VhWmhV7IUkui MuqUUh14Jq35JB0cHdzZ/y5K219R0iaDcpXPDZ069K1tonHO0V O2spTBgZSceBAYHOIv8k+oONqUAmK+EY2PxjRxvCZ0Wd/ZwCch D0zuX
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZAgf8r-DjMmZBzL2VT5QL-t7pmA
Subject: Re: [TLS] Fallback SCSV summary
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: Mon, 10 Nov 2014 20:02:28 -0000
Thanks for the comments! > "The fallback SCSV defined in this document is not suitable substitute for > proper TLS version negotiation. TLS implementations need to properly handle > TLS version negotiation and extensibility mechanisms to avoid the security > issues and connection delays associated with fallback mechanisms." > Added to the introduction (but s/fallback mechanisms/fallback retries/). "If the client receives an inappropriate_fallback alert then the server > intends to support a higher version and the client should retry with the > highest version it supports. Implementors should review the security > considerations section before deciding to make a connection with a lower > version without including the TLS_FALLBACK_SCSV. > Added to Section 4: " [...] SHOULD include the TLS_FALLBACK_SCSV cipher suite value in ClientHello.cipher_suites; see Section 6 for security considerations for this recommendation." and "Fallback retries could be caused by events such as network glitches, and a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an inappropriate_fallback alert in response, indicating that the server supports a higher protocol version. Thus, if a client intends to use retries to work around network glitches, it should then retry with the highest version it supports." > [...] However, it is important to remember that omitting the > TLS_FALLBACK_SCSV leaves the TLS connection vulnerable to version rollback > so it is not recommended to omit the SCSV unless the negotiated version > provides an acceptable level of protection. > Added to Security Considerations: "It is important to remember that omitting TLS_FALLBACK_SCSV enables downgrade attacks, so implementors must take into account whether the protocol version given by ClientHello.client_version still provides an acceptable level of protection." 3. The introduction should indicate that the Fallback SCSV also applies to > DTLS. > New wording in the introduction: "This specification applies to implementations of TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], and to implementations of DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347]." > 4. The IANA considerations section needs to allocate the number for the > alert: > Oops, good point. Done. Bodo
- [TLS] Fallback SCSV summary Joseph Salowey
- Re: [TLS] Fallback SCSV summary Yngve N. Pettersen
- Re: [TLS] Fallback SCSV summary Hubert Kario
- Re: [TLS] Fallback SCSV summary Bodo Moeller
- Re: [TLS] Fallback SCSV summary Yngve N. Pettersen
- Re: [TLS] Fallback SCSV summary Bodo Moeller
- Re: [TLS] Fallback SCSV summary Bodo Moeller
- Re: [TLS] Fallback SCSV summary Martin Thomson
- Re: [TLS] Fallback SCSV summary Bodo Moeller
- Re: [TLS] Fallback SCSV summary Martin Thomson