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

Bodo Moeller <> Mon, 09 December 2013 13:53 UTC

Return-Path: <SRS0=5/>
Received: from localhost ( []) by (Postfix) with ESMTP id 53C6A1AE2BD for <>; Mon, 9 Dec 2013 05:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a1NRu3J3G-Qo for <>; Mon, 9 Dec 2013 05:53:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 607E31ADEBB for <>; Mon, 9 Dec 2013 05:53:18 -0800 (PST)
Received: from ( []) by (node=mreu1) with ESMTP (Nemesis) id 0M3OD6-1VYDN233Fg-00qxVk; Mon, 09 Dec 2013 14:53:13 +0100
Received: by with SMTP id l6so3820866oag.21 for <>; Mon, 09 Dec 2013 05:53:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cyjoTpjTYiRGxN60DPEXYT2NWwL/Lr7zOsSz48vnCjo=; b=gvmGGu4ksF/r2TmJkkAR6gBrgw92jMdzIxcIXN4cLYK1I8xU+fIgXpQgotJzAWRE3n pQltVF0m2cVETXRXCtQSWBvQcl3EB1xezH8c/UHgN5gSg3hCqs0cjBXI2Qtmmdxd68VJ tf3M04azFAePm0vwA+MPXHrNQdTKZatNq7FIuLwhZxBsmXdHv4d2F3lGm+lS/0lcNRev 0pTz5yKOwS7unWQiZvyNLZ5iZMXPMgCJBJvxJ3NqeVwg0gMwIbvp0Lp03+6IEJ601pJQ vTuyr8TP1QfTtr7Fnxd54khv8BTQABvEC1FEW9dTbidD6UFyYFKk4vAPAm7P9Mb5+aWd xYOg==
MIME-Version: 1.0
X-Received: by with SMTP id m6mr12427861oeu.14.1386597191519; Mon, 09 Dec 2013 05:53:11 -0800 (PST)
Received: by with HTTP; Mon, 9 Dec 2013 05:53:11 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 9 Dec 2013 14:53:11 +0100
Message-ID: <>
From: Bodo Moeller <>
To: Martin Rex <>
Content-Type: multipart/alternative; boundary=001a1133458e0c148304ed1a5124
X-Provags-ID: V02:K0:bRSeHon38MdjlVRlVKLi7tj5hVQKKgdI+pYC5hdY6uQ 9jicLMBPMvt15J0+P9KpAKn8+KcQ3qdxFtDX9hHpp7tmLtWe8J tnybVUd4kL8lW0CpJLs/NviYoedi62AQZ4KXx2sj4zkweVo4p7 iu61WPqNn0duX3jWty1q2tbSRNFll37b2w9qascdz4QUQPoC/o vytGiyhIKfJL9s7L7TRlBN5GRxYwwg7Fnz60lqQhpTfIUSAslp TpinxzuaHoCrEFi/FlOcaaFBuX+0OaStBKs79x0RPYEue+fGoD AzzbEkx1JZJdPPvQX2DS8TcnGUiLbvNwTsk8xSG0fwQUYbY4fQ d1DqnYGsq8+26SBMWXJgekcZSOwt6vZ6gK2sO9yR3meUxxQzPN wvG/hXmqDa5GH7Snn96AqhtNNeUJlsd5uexlSNLsiCcr/8Rxyo Q2WMw
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: Mon, 09 Dec 2013 13:53:58 -0000

Martin Rex <>om>:

> > We can start to use TLS_FALLBACK_SCSV
> > ASAP to improve security *ASAP* for connections to *those* servers that
> do
> > get updated (80% or even just 10% is better than 0% -- if only the most
> > important servers that users trust get updated, that's something).
> Huh?  Your proposal is not going to improve the security one single bit.

[....] 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.  And it remains extremely
> questionable, when the handshake would succeed, that the attacker
> will gain anything at all.

To be entirely clear, there's obviously no security improvement from
TLS_FALLBACK_SCSV for clients that never use fallback connections, and for
servers that only have clients without such fallback strategies.

The older protocol versions have some very real security problems.  I don't
think it's relevant that, as far as we know, these security problems are
not currently routinely exploited by attackers.

> For this feature to work at all, the prerequisite is that both
> communication
> peers must be updated.  When looking at a protocol feature that requires
> both communication peers to be updated as a prerequisite, wouldn't it be
> preferable to fix those protocol features of SSL/TLS that we deem necessary
> for reliable security to become negotiable even in the "most conservative"
> ClientHello that clients are willing to fallback to?

Deploying TLS_FALLBACK_SCSV on even just a single server is sufficient to
protect connections to that server.  Clients can use it without having to
wait for all servers to be updated.

If we can also get all servers fixed so that there's no longer a need for
potentially insecure fallback connections, all the better, but it's
certainly going to take longer before clients can be updated to benefit
from that kind of change.  The TLS_FALLBACK_SCSV specification does not
prevent any such effort -- we don't have to choose between *either*
deploying TLS_FALLBACK_SCSV *or* fixing the protocol properly.  (The
TLS_FALLBACK_SCSV Internet-Draft is intentionally agnostic about what a
proper fix would look like.  Once we manage to fix the protocol, clients
would simply stop to send TLS_FALLBACK_SCSV, while servers would continue
to watch for it.)

So I don't agree with the word "preferable": it suggests that the options
are mutually exclusive, when in fact they are not.