Re: [TLS] An SCSV to stop TLS fallback.

Marsh Ray <> Wed, 04 December 2013 23:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A4D71AE2AC for <>; Wed, 4 Dec 2013 15:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x0twUJT6qdJG for <>; Wed, 4 Dec 2013 15:05:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5C6751AE285 for <>; Wed, 4 Dec 2013 15:05:51 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 23:05:45 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 23:05:45 +0000
From: Marsh Ray <>
To: Adam Langley <>, =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= <>
Thread-Topic: [TLS] An SCSV to stop TLS fallback.
Date: Wed, 4 Dec 2013 23:05:43 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:ee31::2]
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(57704003)(377454003)(189002)(199002)(41574002)(24454002)(83322001)(69226001)(56776001)(54316002)(74706001)(31966008)(76482001)(81686001)(46102001)(47446002)(51856001)(63696002)(53806001)(85306002)(77982001)(49866001)(56816005)(59766001)(90146001)(81542001)(47976001)(83072001)(74876001)(79102001)(47736001)(87266001)(54356001)(50986001)(15975445006)(81816001)(76576001)(80022001)(80976001)(87936001)(19580395003)(76786001)(77096001)(65816001)(4396001)(2656002)(74502001)(76796001)(81342001)(74316001)(74662001)(74366001)(19580405001)(85852002)(33646001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB073;; CLIP:2001:4898:80e8:ee31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 04 Dec 2013 23:05:54 -0000

What percentage of these client fallback operations that actual users browsers are doing in the real world are being triggered for reasons *other* than actual server implementation bugs? I imagine this could be a difficult thing to measure. But I can also imagine the obvious client heuristics (if it fails, try again) could easily be triggered by a busy server or simple packet loss. Couldn't this represent a full 1% of connections, especially now that so many users are on mobile devices?

So if a fallback situation was a slow-loading lousy page experience before, what's it going to be after legitimate servers implement this logic? Will servers actively *refuse* legitimate client's retry connections? If so, isn't this just taking an intermittent slow-failure situation and converting it to an even slower but guaranteed interop failure? If not, what good will downgrade protection logic be?

TLS 1.2 was designed to mitigate some serious potential attacks. BEAST demonstrated these attack vectors could be practical.

We need to recognize ad-hoc client fallback heuristic for what it is: a security vulnerability.

Therefore, clients MUST NOT auto-downgrade.

Therefore, broken servers and middleboxes need to clean up their act or GTFO.

This was always clear to anyone considering it from a protocol security angle. But the strong desire for interoperability and the absence of documented attacks in the 2000's made it hard to argue from principle.

Do we need an RFC a' la 6176 to give security-minded developers an explicit argument from authority?

- Marsh

P.S. I admit to being somewhat skeptical when RFC 6176 was being proposed. But I mentioned it in a meeting the other day and there were literally nods of understanding all around the table. Thanks!

-----Original Message-----
From: TLS [] On Behalf Of Adam Langley
Sent: Wednesday, December 4, 2013 11:20 AM
To: Manuel Pégourié-Gonnard
Subject: Re: [TLS] An SCSV to stop TLS fallback.

On Wed, Dec 4, 2013 at 2:12 PM, Manuel Pégourié-Gonnard <> wrote:
> Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is 
> not servers that don't implement version negotiation correctly, but 
> MITM actively doing a downgrade attack (and faulty middleboxes, which have the same effect).

I think the chain of sadness goes like this:

1) Some servers don't implement version negotiation correctly, or have other bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a Chrome experiment where we removed SSLv3 fallback for Google properties because it looked, to the client, like an attack. But, since it's a MITM proxy, it's an attack that the user has authorised.


TLS mailing list