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

Bodo Moeller <bmoeller@acm.org> Thu, 05 December 2013 21:43 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 ED2E31AD8DC for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 13:43:39 -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 o8Hv_1-YDXVC for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 13:43:34 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A60491AC3DA for <tls@ietf.org>; Thu, 5 Dec 2013 13:43:33 -0800 (PST)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MgHFG-1WCFjq3xV0-00NKx5; Thu, 05 Dec 2013 22:43:29 +0100
Received: by mail-oa0-f47.google.com with SMTP id k1so19198975oag.34 for <tls@ietf.org>; Thu, 05 Dec 2013 13:43:27 -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=vDNGYEzsyEYzzBK6YEqvDHD7fNlyowVmGfPRr+jddgk=; b=m9DCrv/exiQJpe+Y7UXVs8Vo7CZce3gyqYyDejTQJSnuPiMD6NAzzRnBszGQwqLZc6 GFap+xkY9MhiIrNIQ3q+EYzlN+J459EBx9MNopIV0h6sMarCPjSaIVsjlCdBEi6zux43 Bnw0daIFPf1eQ1HDxs1hxqzm72hnOqYuCKwW4qt4MsaNhC+XThIWobgY1d8MtUjGVAw7 KW0sSqsUi9iq4vVOi6Ty6HE13Rc2y0dT/VpfzR3fOpiH+jwlnRbw3V9WPj/PvvG6QwdX NhIw0DiZKzPhpa6Hz/OyeOvoa2N5NUkHKPDPNOCKWQ8jpOhARN9sjCs2eHxEJnSMWsII JzRg==
MIME-Version: 1.0
X-Received: by 10.60.116.230 with SMTP id jz6mr89258oeb.21.1386279807649; Thu, 05 Dec 2013 13:43:27 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 5 Dec 2013 13:43:27 -0800 (PST)
In-Reply-To: <b6717ff7f2b94f4dbae2bc99dad7c2ec@BY2PR03MB074.namprd03.prod.outlook.com>
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> <CADMpkcKGs_=Skd2_NzdyNvQB2WachTtBGNPx+5QHxwRhQ7Ln_w@mail.gmail.com> <b6717ff7f2b94f4dbae2bc99dad7c2ec@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Thu, 5 Dec 2013 22:43:27 +0100
Message-ID: <CADMpkcJUDDKf2vQv5=r9UThqQkfJg=p7fr-jS-URgZLEULwtBQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e0115e84a7e90a104ecd06ba4
X-Provags-ID: V02:K0:i5IMj9zMJcrhSKmfSQL/vAb5k6ew8D53ZDQCr67KAsl j0f6eCEwVv3Zh22EATNgisKZwcApCdUnvAkDtRZ5/m5EOu2rGl eahbN3amC/wuv0pNWDswYUaN8TXbfDmx4T7/Uu+z+iRJVH7JkL SVno2bT7wUKlTLpVCAORdmGjAB0SUTnCp7Clm60PhShqtacNDE UDaPSJCJC4o3UvUnGEzJ33oadaImQSYEcDJlXUrCed8dpHdYzX zlfrlehwg/YgJJ39fPi64aOeT//8T9LSJRp/uFRMCc3x9vj77V KNY7+n0oC52bGM7KKaNjWa0Fd4q+qJZijr3xtDCziYm50nbQdA 4jU1OwHGOsszARMCQTQClYbh7sZrDmCnA0qeL4ZXzfMu8ViCRi IRdFKCtHY7qSd+TLLS8OG+fCADU87M2JbUFqySTyYw5fQ1OtlV 7FpC1
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 21:43:40 -0000

Marsh Ray <maray@microsoft.com>om>:

> ClientHello.client_version
> >    The version of the TLS protocol by which the client wishes to
> >    communicate during this session.  This SHOULD be the latest
> >    (highest valued) version supported by the client.
>
> That sounds to me like the client MAY retry with record.version={3,0},
> but it SHOULD still send ClientHello.client_version={3,3}.
>
> So for clients that follow RFC 5246 recommendation, what is gained by
> sending TLS_FALLBACK_SCSV?


In this case, TLS_FALLBACK_SCSV is not sent.  TLS_FALLBACK_SCSV is all
about fallback connections in which the client deviates from the above
recommendation, and sends a lower ClientHello.client_version (i.e.,
pretends that it doesn't actually support the latest protocol).  That's
something that clients actually do, because following the RFC
recommendation doesn't allow them to interoperate with all servers in
practice, unfortunately.



> Why couldn't we instead recommend that
> servers reject with *any* connection attempt for which
> ClientHello.client_version < "highest version supported by the server" ?
>

I think you haven't thought that through.  If we did that, it would render
version negotiation pretty much useless: you couldn't ever upgrade servers
to a new protocol version before *all* clients have been upgraded to
support that version.


The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
> is that servers are not actually in a position to know the highest
> protocol version that the client supports.
>
> Thus a server would have to refuse *any* connection for which the
> client sends TLS_FALLBACK_SCSV set.
>

I don't follow.  Servers would refuse those connections for which the
client (1) sends TLS_FALLBACK_SCSV and (2) doesn't advertise support for
the server's highest supported protocol version.  They don't need to know
the highest protocol version actually supported by the client.


Sending a flag to say "oh by the way I'm lying about my highest
> version" is not a complete fix.
>

It's obviously not a *complete* fix, but it's a fix that addresses relevant
security problems, *and* can actually be deployed (right now, that is,
without having to fix every broken device on the internet first), *and*
does not get in the way of a complete fix.



> I only see one correct solution: ripping out this auto-downgrade
> logic from clients and putting these broken servers and middleboxes
> on notice that they have no place on a secure network.
>
> Only then will environment begin to heal and as it does page load
> times would become a bit faster.


That's the theoretically correct, non-kludgey solution.  However, the
reality is that client implementers have found it necessary in practice to
implement protocol fallback strategies to improve interoperability (and
users tend to prefer bad latency over unresolvable connection failures; I
fear that trying to explain some game theory on browser error pages
wouldn't help).  In case we manage to evict every server from the internet
that doesn't tolerate TLS 1.2 Client Hello message, that need would go away
for now -- but as soon as we start to deploy TLS 1.3, we might then find
out that new servers are around that work fine with TLS 1.2 but don't
tolerate TLS 1.3 Client Hello messages, and we'd be back to square one.
 There are some things we could try to prevent that, but if this Correct
Solution[TM] doesn't work out, it'll be good to have TLS_FALLBACK_SCSV
around as a backup.

Bodo