Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Bodo Moeller <bmoeller@acm.org> Fri, 17 October 2014 09:56 UTC

Return-Path: <SRS0=LHIJ=7I=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 392421AC3B5 for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 02:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.362
X-Spam-Level: *
X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_LOW=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rQJnPfVpag7X for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 02:56:34 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081AA1ABD39 for <tls@ietf.org>; Fri, 17 Oct 2014 02:56:34 -0700 (PDT)
Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0M21dP-1XzUQu2ifz-00u1mz; Fri, 17 Oct 2014 11:56:32 +0200
Received: by mail-yk0-f170.google.com with SMTP id 20so201423yks.1 for <tls@ietf.org>; Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.203.114 with SMTP id e78mr10402247yho.47.1413539788350; Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 02:56:28 -0700 (PDT)
In-Reply-To: <CAFewVt4fDxTk2hFXohxcj5wq62nv2qvxrkoP3aCpw7HpEnMOGQ@mail.gmail.com>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <CAFewVt77caT8kDPyKhT3Bqn5T+uRKA79n_F24VGnd+abMe6=zA@mail.gmail.com> <CADMpkcJmvZ7Zra9TJ9usnmcgYPnsKaykwOuXEFbDATT=qgWEAg@mail.gmail.com> <CAFewVt4fDxTk2hFXohxcj5wq62nv2qvxrkoP3aCpw7HpEnMOGQ@mail.gmail.com>
Date: Fri, 17 Oct 2014 11:56:28 +0200
Message-ID: <CADMpkcKF8hExnqztuDym1NwTsJRSSoz4=aTeFKfP58tokFf8sQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e0158c7c4f5f02405059b6056"
X-Provags-ID: V02:K0:/++NlE5ixiuSWnzjj4kGorPuF6ZN96iPjUv+IsQ+B9l +qANbj8nHrrB6YHc3rpYewJmEofYWc/ozMaNDzd2iKxHdJHeWw 2fMwXDKSYAD6i0lT6yYrw26nxP7os0YZYtO1x6IUO5IE0UzGgQ 3YOByazMMVYcyh4crQAJ0+2yvgBbKkTQn7SSAyfkAjtJw2n3yO obf9OpW2Eum64rupKrXIldojFaeeTsGLOb6JplyxJSC9Ky+/kB DadpQnvHH/JOKuLBAEAzoCBbTXrpfbet3+rI4XluuY0DIyMpqw fKVkaNaacrmlHlpvEIbP4MJzQfe+3mgxavuY2cMaXXooM7hbGh aF51EK5AEj5NMKroTjUFL/7jBIH05owkM4rtDGrtN+eqtuTFsF LzqvRmbGrZiKUjJOCASe0xXKbyJZ+jIMSN9LNuvG0CpET4mZcU scKGy
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qom8bQHCUjqb_hlxJnlz2F5WG-k
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
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: Fri, 17 Oct 2014 10:41:25 -0000

Brian Smith <brian@briansmith.org>:

> Bodo Moeller <bmoeller@acm.org> wrote:
> > Brian Smith <brian@briansmith.org>:
>


> >> It seems like the draft should also advise clients that they MUST NOT
> >> do the False Start optimization if the server does not choose the
> >> maximum version of TLS that they support. For example, if the server
> >> chooses a version less than ClientHello.client_version, or if the
> >> client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
> >> start. Currently the draft says nothing about this. Because of False
> >> Start, there are several downgrades that are still possible even with
> >> the current downgrade-SCSV-enabled Chrome and Firefox, for example.
>


> > This isn't specific to fallback retries and certainly not to the
> > TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
> > mechanism for protocol version negotiation), so I think an updated
> version
> > of the False Start specification would be the right place to set any
> strict
> > requirements for this. However, it would make sense to *mention* and
> discuss
> > this aspect in the TLS_FALLBACK_SCSV document (non-normatively).
>


> If version downgrades during False Start are to be tolerated, then at
> a minimum the security considerations of this draft must point out
> that the mechanism is simple to subvert (partially, at least) when
> False Start is used.
>

Exactly, but the detailed recommendations should go into an updated False
Start I-D instead; I can do that.  Specifically, that spec could say that
if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
SHOULD be disabled for that handshake.  And then we'll also have to say
that the client similarly should not use False Start with any protocol
version for which it would send TLS_FALLBACK_SCSV in fallback retries
(since otherwise the former recommendation wouldn't achieve anything.)  The
TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
reminder that allowing False Start with older protocol versions can be
problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
can't address.

So, I believe that your suggestion for client behavior is absolutely spot
on. My point is just that the very same issue w.r.t. False Start and
version downgrades exists if the client doesn't do any fallback retries --
and those who implement such clients shouldn't have to read the
TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
into the False Start spec.


It is true that, as the TLS 1.3 draft is currently written, browsers
> will have to do non-secure fallback to TLS 1.2 often when they enable
> TLS 1.3. I agree, given that current situation, that that is something
> that should be allowed. But, I disagree that it should be allowed to
> let a MitM downgrade a connection all the way to TLS 1.0 w/ the False
> Start mechanism, especially when the server has implemented the
> downgrade SCSV in an attempt to prevent that.
>

Right.  (Except that I don't think that you *disagree* with me on this.)


[...]

> > That said, the question whether the mechanism has relevance for
> weaknesses
> > other than those found in CBC cipher suites can be answered in the
> > affirmative. For example, if clients fall back to SSL 3.0 without TLS
> > extensions, they can't use ECDHE and thus may lose forward security.
>

No. When false start is allowed for RSA key exchange, the initial HTTP
> request (including auth credentials), even if both sides implement the
> downgrade SCSV correctly, an attacker can still force the client to
> send the initial HTTP requests (with auth credentials) using a version
> of its choosing and using RSA key exchange. In Chrome and Firefox, the
> downgrade to RSA is prevented by their False Start policies, not by
> the downgrade SCSV.
>

Here I don't agree. The downgrade to RSA is prevented by having *both*
(don't allow False Start here, *and* use the downgrade SCSV). Not allowing
False Start wouldn't have helped at all without the SCSV for fallback
retries, and using the SCSV wouldn't have been a complete solution if False
Start was enabled with legacy protocols.


Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
> saying it is surprising that the downgrade SCSV doesn't prevent
> version downgrades, and that should be fixed.


Right. I'll mention that potential surprise with False Start in
TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
the False Start specification.

Bodo