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