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

Bodo Moeller <> Thu, 05 December 2013 11:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C79AA1ADF26 for <>; Thu, 5 Dec 2013 03:16:25 -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 Th460gbblYjc for <>; Thu, 5 Dec 2013 03:16:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1DFFC1ADED5 for <>; Thu, 5 Dec 2013 03:16:24 -0800 (PST)
Received: from ( []) by (node=mreu1) with ESMTP (Nemesis) id 0Lvx1t-1VWAhS2wwP-017kk6; Thu, 05 Dec 2013 12:16:20 +0100
Received: by with SMTP id i7so18005583oag.24 for <>; Thu, 05 Dec 2013 03:16:18 -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 :content-type; bh=5pkZ93TksxLjtHu0AEVBvgCE2ZztXfDPtzxjguv4kaU=; b=Oh4XG78/umkybRB/wp0JRfPjvu+SB28jEVsjdQ6XCGuPjxIuP8bCl0QjTg4MFpYUfi NJzwqwyJ8Y0KeYUq1n6ZBa2fQfk/EY4kjrgJvAGs03/I/UnvSGsA4FY/rrFpVxVYwYYz gdOWM+kttPFLbfQ94d0HSkLnpHF+GjsEn954PtQCAiZyn9b4YVTLcxmpDIJ6Yv+v8XXa kWpgeAOxJpTkPJ/bkH2X2acTIpoa6+1nTwq6ZyL7UAXYoa760gDiCX2RPKeDB/Q3jiGr ygcx7uqLqbu3U844N/fgPIKnTnSDQyG3KIXSla+wrQsktYjKwmw6qA3jmJPAeLpw+LV+ w/Og==
MIME-Version: 1.0
X-Received: by with SMTP id sd7mr226772obb.70.1386242178475; Thu, 05 Dec 2013 03:16:18 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 03:16:18 -0800 (PST)
In-Reply-To: <op.w7lfuxrh3dfyax@killashandra.invalid.invalid>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <op.w7lfuxrh3dfyax@killashandra.invalid.invalid>
Date: Thu, 5 Dec 2013 12:16:18 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary=e89a8ff1ce9e9ef0e804ecc7a8ad
X-Provags-ID: V02:K0:ARjdo21YP3sj+6CTkUdQbb8qxqbaQJV50Iid3vA5RWU x0HGRbToXPZO5HFHGqRrjWnqrvcFeoZ5ANvqyQwo3BM2MgpIBB gNQXnhSrJW97kScHAVe6TIs9mXOtzgP2L1pCsAt9NdP0rYe+3n sOhUSb/HKDT6/IJDWN0fyIxAK9Ahq7BUxPx79XVLV7j28DAt5s +F3hdFaJjpJ0k0tiQf8me9AU5jTbVtg8JwBIW5V2+RONkO9Tpu FsmFFMbanc0PL5fxAe8h9BtUIJNrcsdcm/f4KWSEwh5Cr+71I6 gMJa1RbFDeCvzd43IKwVTcFKaFwZctfH/IJhgR+t7CNw0CpRzu NuZy4RlOM1tUFoV3+23IRcHycZH/f7hRCHaZQ41ijfrcKXfqEZ hvzVLN0nOsIry+H9aQ3fUaGJHfpjN7jZG4+dmn8EttxmiWRPw2 7EpFK
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 11:17:38 -0000

Yngve N. Pettersen <>et>:

The SCSV proposal very likely will not "break the web", but my objection is
> that it will require updates to all the servers, and not just the clients,
> and thus take too long to deploy (case in point: 4 years after the Renego
> problem was discovered, 20% of servers are still not patched). Given that.
> 14 years after TLS 1.0 was released, about 1% of servers still only support
> SSL v3. I do not have high hopes of having SCSVs fully deployed in 15 years
> (unless client vendors decide to, or have to, "break the web").
> My suggestion have been to update the clients to refuse to use fallback
> when connecting to servers that implement the Renego patch. This have the
> benefit of using a proxy for correct version negotiation, which is already
> deployed on a majority of servers. The drawback of my proposal is that the
> proxy indication is not perfect; there is a small fraction of patched
> servers that are version and/or extension intolerant, and there is a much
> larger fraction of servers that are version intolerant for whatever version
> bytes TLS 1.3+ will use. Some will call the first group as "breaking the
> web", while most will probably agree that the second can definitely be
> called "breaking the web".

> The question is, if client vendors agree to "bull through" and refuse to
> fall back, will the server vendors and web site operators fix their
> implementations, and if so, how quickly? The best option in such a scenario
> would probably be a coordinated same-day release  (alternatively flipping a
> flag) of updated clients, particularly browsers, so that web sites cannot
> use the "switch browser" "advice" for fixing the "browser bug". (Flipping a
> flag might be the better option, since this will allow the updated browsers
> to gain a sufficiently large marketshare before changing the behavior)

As I've mentioned, the two options are not mutually exclusive, so I think
you are constructing a false dichotomy.  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).  Servers
that aren't version tolerant or extension tolerant will still be just as
broken; having TLS_FALLBACK_SCSV specified doesn't mean that clients are
generally *expected* to fall back, so doesn't affect plans for a fallback
flag flip day or anything like that.