Re: [TLS] An SCSV to stop TLS fallback. (Martin Rex) Tue, 26 November 2013 02:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 567D31ABD2A for <>; Mon, 25 Nov 2013 18:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JBs2Ubg1blsZ for <>; Mon, 25 Nov 2013 18:19:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D65011AE122 for <>; Mon, 25 Nov 2013 18:19:25 -0800 (PST)
Received: from by (26) with ESMTP id rAQ2JOc3011775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Nov 2013 03:19:24 +0100 (MET)
In-Reply-To: <>
To: Adam Langley <>
Date: Tue, 26 Nov 2013 03:19:23 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: "" <>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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, 26 Nov 2013 02:19:28 -0000

Adam Langley wrote:
> Sad as it is, in order to work on public Internet all browsers
> implement TLS fallback: in the event of a handshake failure they will
> retry the connection with a lesser SSL/TLS version.
> This means that an active attacker can disable AES-GCM support and,
> ultimately, ECDHE if they push the browser back to SSLv3. It would be
> good to finally do something about this.
> Thus I'd like to propose the design of an SCSV with which we can move forward:
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.

We keep this proposals for newly creating interop problems keep
coming up on this list?

How about instead fixing the negotiation so that AES-GCM&AES-CCM
can be sent in whatever ClientHello there is (including SSLv2)
and an additional SCSV to signal availability of a specific subset of
ECDHE that can be used without a TLS ECC extension, such as the subset
that is supported by Windows 7+?

If there is a problem in negotiating what _we_want_to_do_, because the
installed base does not like the kind of negotiation that was originally
proposed to be used, then the pragmatic engineering approach will be
to define an alternative negotiation of at least a useful subset
that will be compatible with the installed base, and which will not need
to be stripped from a "conservative fallback handshake" -- and therefore
will be resilient to downgrade attacks, and cope with retarded middle boxes.