[TLS] An SCSV to stop TLS fallback.

Adam Langley <agl@google.com> Mon, 25 November 2013 23:28 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C22491AE0CC for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u8dn4shUEKEE for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C01AE0BB for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: by mail-vb0-f53.google.com with SMTP id g10so3222890vbg.26 for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=jsnQxZvGMiz8/WTv/lHGW5DuBrzNMV0prfRy6K5hbkqOsiFwyrJbzFGP0YPL1VeFE6 HAb6iFtBVIgLojYaKdo8ubKjKGwqhSps6fSbL+Fd773aHzV22ttJP4y9P5m3VnOxiHXX kKaiI9NcI1noVahK+k7ttKJaaxSf/Lv7MZcmqLAXTl1TD4ic8Iw1HFt6U+VX3yO7KPrk iwR/wNRX+La+Wov1gi6aeK8FaF0VjRFkoBAvHe0dvTGa0sylKAtvfLjXcafXlISaokmR NrlTaPLYw/4+l9EtbdrHoj5cveQjSCHk4ykgAfIdfdcovWBxtWfqwE+YC1jxIZNAtMZ2 UfzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=lOJTQt7vvZQQz4e2aNZS2/+kuissaLZFXleIwu58oaw8gPtS1f7SdOk9/7VeC+gNvb hZAqMDw1edrwwJckOIz+HK+o+4sWywNxa3znvg7ZcN40tq3/GYQil7C1BaSFUIKz6AYv qLi2S58FtLctkGg49e2mzpiVWgItXrtLLA8/+FQwNPDNnuJR9qDLSaJbae576KCH60SD g/MlHlWfMCDwbBImDvFo2gYKiQOK+35pmUD0cZGrxjWrBK3JYXRKJ02U9fgr0roPg3Fa lYgZqYz3ZMYWUgFVAJqaWVyltDxg8wALfXzT6AUcJ0/JYf5/rp023FEDzm8DP9lmcpSs BzDA==
X-Gm-Message-State: ALoCoQnJOQ+UFHktYT1IGR9iBMKdXTtyXX2CZarzuAAItom9agbuC7B+i/F6QJ9dCBsy83MeQoZp5lJSnUphCbXYSI11vOsgsw0sfkFMyjhGUZzDZD8+QFi7EcIaj+V1EJK2eDeNI2+0uD/B92wSXDoS6j/s3psi7gaq6zE7CBAPECdUxNYdh+GmjZmhE/bBCZrtBkr8e+s2
X-Received: by with SMTP id eh3mr2807040vdb.29.1385422098224; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 25 Nov 2013 15:27:58 -0800 (PST)
From: Adam Langley <agl@google.com>
Date: Mon, 25 Nov 2013 18:27:58 -0500
Message-ID: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] An SCSV to stop TLS fallback.
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, 25 Nov 2013 23:28:20 -0000

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.

As I've mentioned before, with Chrome 31, we removed support for
falling back to SSLv3 for Google sites. With Chrome 32, we were
planning on removing all fallback for Google sites.

Chrome 31 has been released and saw a fair amount of breakage due to
an anti-virus that (in some configurations) acts as a local MITM and
had bugs. Previously it was depending on browsers falling back to
SSLv3 in order to function at all.

I've since contacted a few other anti-virus and MITM vendors and asked
them about the Chrome 32 change. A couple have informed me that they
will break, at least in some configurations, if Chrome removes all
fallback because they cannot do version negotiation correctly.

I had expected the problems to come in the form of DPI devices sniping
TLS 1.2 connections with injected RSTs rather than MITMs. These
experiments in Chrome 31 and 32 were designed to probe how large a
problem they were. The plan was always to gather information and then
figure out a general solution that avoids having a special case for
Google sites in Chrome.

Since the MITMs are turning out to be the problem, I think the plan
needs rethinking as the general solution need not break MITMs and thus
could be deployed more easily.

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

This will not break MITMs because they will not process the SCSV. Any
vendors that try to support the SCSV while having bugs that need
fallback will find out when things stop working. But that, thankfully,
will be their problem based on the Universal Rule of Users: the last
thing that updated is to blame.

Of course, this doesn't mean that firewalls won't turn out to be a
problem but, at the moment, we can't even figure that out because of
the the broken MITMs. We can't protect MITMed users, but it would be
nice if they didn't ruin it for everyone else.