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

Manuel Pégourié-Gonnard <> Thu, 05 December 2013 08:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 534DB1ACCD8 for <>; Thu, 5 Dec 2013 00:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WCm2GUwi3cfg for <>; Thu, 5 Dec 2013 00:51:44 -0800 (PST)
Received: from ( [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by (Postfix) with ESMTP id 814B21AD739 for <>; Thu, 5 Dec 2013 00:51:44 -0800 (PST)
Received: from (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by (Postfix) with ESMTPS id 8EA9C160BF for <>; Thu, 5 Dec 2013 09:51:40 +0100 (CET)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 6090B27197 for <>; Thu, 5 Dec 2013 09:51:39 +0100 (CET)
Message-ID: <>
Date: Thu, 05 Dec 2013 09:51:38 +0100
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Thu, 05 Dec 2013 08:51:46 -0000

On 05/12/2013 00:05, Marsh Ray wrote:
> 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?
It seems to me Adam already answered this argument, and his point was that
browsers don't retry plain HTTP connexions anyway, so the situation with
TLS_FALLBACK_SCSV with respect to intermittent failures situations will not be
very different from what it is with HTTP: the browser will show a failure page
and the user will hit the "retry" button.

So, it's not turning an intermittent failure into a permanent one: it's merely
turning an intermittent failure that may not have been visible to the user in
case a silent fallback into an intermittent failure visible to the user.

The only drawback is, as you note, the failure will be slower, compared to what
it would be without any fallback attempt. So the question is, which is worse:
1. Slowing down the display of an error message in case of intermittent failures
with a legitimate and compliant server (the situation with fallback and
2. Being unable to communicate with version-intolerant servers (the situation
without any fallback)?
(I leave out the 3rd option: being vulnerable to MITM downgrades, which I think
we all agree is bad.)