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

Bodo Moeller <bmoeller@acm.org> Thu, 05 December 2013 11:16 UTC

Return-Path: <SRS0=loW3=VM=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79AA1ADF26 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 03:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th460gbblYjc for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 03:16:24 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFC1ADED5 for <tls@ietf.org>; Thu, 5 Dec 2013 03:16:24 -0800 (PST)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lvx1t-1VWAhS2wwP-017kk6; Thu, 05 Dec 2013 12:16:20 +0100
Received: by mail-oa0-f51.google.com with SMTP id i7so18005583oag.24 for <tls@ietf.org>; Thu, 05 Dec 2013 03:16:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.182.143.103 with SMTP id sd7mr226772obb.70.1386242178475; Thu, 05 Dec 2013 03:16:18 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 03:16:18 -0800 (PST)
In-Reply-To: <op.w7lfuxrh3dfyax@killashandra.invalid.invalid>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com> <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com> <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com> <CALTJjxEDXsmdzY4+OH2AFcYfMW5zY=V4PzQK3hqB1WrqjRJB+g@mail.gmail.com> <CADMpkcJO8xZ41DDnofPinm2SMkhONW7w+cODGwnVpJtB5o8OqQ@mail.gmail.com> <CALTJjxGTmSPRNWfbRrpkFQb3nBwY63fUros+4fLsXjum=q3urA@mail.gmail.com> <529F7E9D.80302@elzevir.fr> <CAL9PXLwVQ=GmZXGrh4+VEd-u1dhhvThKHfVf0qRShcR+LdExTQ@mail.gmail.com> <f30ced5319a9451080562a1d2d8004f8@BY2PR03MB074.namprd03.prod.outlook.com> <op.w7lfuxrh3dfyax@killashandra.invalid.invalid>
Date: Thu, 5 Dec 2013 12:16:18 +0100
Message-ID: <CADMpkcKGs_=Skd2_NzdyNvQB2WachTtBGNPx+5QHxwRhQ7Ln_w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
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-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 11:17:38 -0000

Yngve N. Pettersen <yngve@spec-work.net>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.

Bodo