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

Daniel Kahn Gillmor <> Fri, 06 December 2013 18:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C86EA1AE111 for <>; Fri, 6 Dec 2013 10:45:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1q6pw1YrKe2F for <>; Fri, 6 Dec 2013 10:45:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC60A1AE087 for <>; Fri, 6 Dec 2013 10:45:41 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 7941BF984 for <>; Fri, 6 Dec 2013 13:45:36 -0500 (EST)
Message-ID: <>
Date: Fri, 06 Dec 2013 13:45:31 -0500
From: Daniel Kahn Gillmor <>
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
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FNVI5LqWPlJAchxpwU9IP9eUCRq0gUDHf"
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: Fri, 06 Dec 2013 18:45:44 -0000

On 12/06/2013 01:25 PM, Martin Rex wrote:
> So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
> of the TLS protocol not at all, or cause a fatal handshake failure.
> And very few, if any at all, of the situations where the handshake fails,
> will be instances of an active attack.

This is probably also true of X.509 certificate validation failure as
well, since there are more self-signed or expired certificates in active
use than there are active MITM attackers.  Are you suggesting that TLS
would be better off not checking certificate validity?

> And it remains extremely
> questionable, when the handshake would succeed, that the attacker
> will gain anything at all.

What the attacker can gain presumably depends on what features the
client is willing to sacrifice during fallback.  Presumably, the client
gives up specific features of the newer versions: e.g. AEAD, when
falling back below TLS 1.2, or possibly all TLS extensions for fallback
all the way to SSLv3 (to accomodate old extension-intolerant SSLv3 servers).

It looks like you're saying that none of these more modern features are
useful tools in defending against an active attacker.  Do you really
think that?