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

Bodo Moeller <bmoeller@acm.org> Fri, 17 October 2014 13:44 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 258C61ACDDA for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 06:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 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, 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 E-_f19CuAvpU for <tls@ietfa.amsl.com>; Fri, 17 Oct 2014 06:44:45 -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 C988D1ACDB5 for <tls@ietf.org>; Fri, 17 Oct 2014 06:44:44 -0700 (PDT)
Received: from mail-yh0-f45.google.com (mail-yh0-f45.google.com [209.85.213.45]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0McAjL-1XOxzi0WaF-00JbfG; Fri, 17 Oct 2014 15:44:41 +0200
Received: by mail-yh0-f45.google.com with SMTP id b6so364283yha.18 for <tls@ietf.org>; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr3857494yht.164.1413553479936; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Fri, 17 Oct 2014 06:44:39 -0700 (PDT)
In-Reply-To: <5440CC7F.1020608@brainhub.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <5438CFEA.7000401@brainhub.org> <5440CC7F.1020608@brainhub.org>
Date: Fri, 17 Oct 2014 15:44:39 +0200
Message-ID: <CADMpkcLdSCLb5LzBjufVF4h7X=HFPTgHq4fN+zdc6zrM+ijXaA@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8f642a980af70505059e91cd"
X-Provags-ID: V02:K0:erd3n5Hq5xZLdPjCubIK48LCXZ1HmNjaIAzbwAuTRRn zS5V4iGQZHmPtJRLxo1PknRUlV1L73uvY+2NnkSqbYyxNoVOTm vKGoy9YxFH5PczsF0/pYYJkkKJud8xqLOmIr2e9xZyowPwP8jp 4MD6Aus17kcjzMSRa4jJ1rNS3JU125y3zzubJvQsxDqo8c3BKX Gr/L5gkGjGFiqIfBLGnPR7fsaIXh88TNP7mDvzXmqEBKQktARy f+iGkGGjhaSckhbS6QnN1Ap1sQnvE++Nq47BP7pv/HoHIK2SFl /abcRX7Qpo4uvPaZxnMvYYa9Yz5eMc5/5B4yBX6GcpddCDo9ID 7doVIH+G5q3Wu3cScCmTQGs/Z1SwyqSmHlIPeKlFRDjV8nBuSz PKoJ+1CmiXRBiVy78HD/d9Kc2laY69r6sp52Fzjy3Vvya8wxzi suf7J
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0aH-ABVsWb5X0kigl4oN4Eo6ZIg
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 13:44:47 -0000

Andrey Jivsov <crypto@brainhub.org>:

(On handling of the downgrade to a recent versions of the protocols, i.e.
> TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>


> The draft -00 asks the server supporting TLS 1.2 to fail the TLS 1.1 in
> some cases, while significant amount of traffic on the Internet goes over
> TLS 1.0.
>

Right. If both the client and the server *do* support TLS 1.2, we want to
ensure that they won't unnecessarily fall back to an earlier protocol
version (thus losing the benefits of TLS 1.2). If one of them only supports
an earlier protocol version, they'll still be using that one --
TLS_FALLBACK_SCSV doesn't get in the way for that.


Today, for example,

   www.wellsfargo.com, citibank.com, and bankofamerica.com don't support
> TLS 1.1 and
>    mozilla.com doesn't support TLS 1.2.


Note that this isn't the kind of downgrade that TLS_FALLBACK_SCSV is about.

All of the above sites, and indeed most TLS 1.0 sites on the internet, will
properly negotiate the supported protocol version. That is, the client can
send a Client Hello advertising support for TLS 1.2, and the server will
directly respond with a Server Hello selecting TLS 1.0 or TLS 1.1. There's
no fallback retry in which the client adjusts its advertised protocol
version, and thus no need to send TLS_FALLBACK_SCSV.

Also, even if the client *does* retry with a lower protocol version (TLS
1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with TLS_FALLBACK_SCSV),
such as because the initial handshake failed due to some network glitch,
these servers would still accept the new handshakes according to the
TLS_FALLBACK_SCSV specification. The spec only requires them to reject
Client Hellos with TLS_FALLBACK_SCSV if the advertised protocol version is
*lower* than the maximum protocol version supported by the client.



> I propose the following change that allows to do exactly what rev -00
> says, but now enables more tolerant server behaviour.
>

As discussed above, I don't see any problem that this change would address.

The spec intentionally gives exact rules for server-side behavior, allowing
the *clients* to fully drive the fallback strategy and determine when it's
OK to fall back to an earlier protocol version and when it's not (with no
server-side heuristics involved).

Bodo