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

Bodo Moeller <bmoeller@acm.org> Wed, 15 October 2014 19:19 UTC

Return-Path: <SRS0=qaHA=7G=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 9CF311A9138 for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 12:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.938
X-Spam-Level:
X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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=ham
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 LYl5ygQUBl_l for <tls@ietfa.amsl.com>; Wed, 15 Oct 2014 12:19:46 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 2708F1A1B1A for <tls@ietf.org>; Wed, 15 Oct 2014 12:19:46 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MF4EF-1XOrBz0ZRb-00GIbN; Wed, 15 Oct 2014 21:19:44 +0200
Received: by mail-yh0-f47.google.com with SMTP id c41so911162yho.6 for <tls@ietf.org>; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.22.228 with SMTP id t64mr6928456yht.164.1413400782573; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Wed, 15 Oct 2014 12:19:42 -0700 (PDT)
In-Reply-To: <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
References: <543E2D81.1050700@redhat.com> <20141015185216.EE6371AEDF@ld9781.wdf.sap.corp>
Date: Wed, 15 Oct 2014 21:19:42 +0200
Message-ID: <CADMpkc+-=nmxfXM7A6TDo7t=gTPtf1fZfCCftStONGjry1av3A@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Martin Rex <mrex@sap.com>
Content-Type: multipart/alternative; boundary="e89a8f642a9892179405057b03e2"
X-Provags-ID: V02:K0:G1yJ85HBUyLrkqZSjU/efajovBAPGZfw22/Kb1AEMQH Ak8FmmgqmlynXSpN5HUiMPRbgxvmbQMzenRGZmeMU7KyoSwAbc ZkLNerJ4Hbs/K7tm7ETWoHP9uQ5T/X1oeaxtqGDhQx38zuKyLs IEUxRPJQxef71CgdtrnSQvqdYEaAZ3MPaOyf2UhAMtCwlla4ld nGkNiJOQu12B2WA6BwrunupCk8lnu0wEEaU1YBp160+7Xogw8l dVTKa8gaIYRe70oTLjpFDqL70BU1zU7b2QutT94DHVkoppqRLJ rT1/aRw9rX2G6Ml4O/ZIGEu1W+4W1KOARiyYFovwJ7HgbrxQ7/ Lqq49noMZk+eVw0wCQCKhP9niL4Uur/1HkOhFdFguDZiqWNpKk i2+T26n6c6IwRXPDMva7a4jKT53TuHhT9NuQ9FsEGtckr1thJU PszAH
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fOL4-5bbf6eHTlyWEbAXYAwf1JI
Cc: tls@ietf.org
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: Wed, 15 Oct 2014 19:19:48 -0000

"Martin Rex" <mrex@sap.com>:

> I'm also strongly opposed to this proposal, because it does not provide
> any value--there is not one single *additional* TLS handshake that it
> will make succeed,
[...]

> The "downgrade-scsv" has the effective semantics of
> "kick me if you can read this", which is pretty silly on my scorecard.
>
>
> A reasonable alternative SCSV would have the semantics
> "Dear Server, I'm a new, full-featured client and would really like
> to send you a full-featured ClientHello, but didn't dare doing as
> the first message on the connection because of all the old broken
> servers out there which choke on feature-rich ClientHellos".
>
> And a new Server's response to such an SCSV should be to
> respond with a ServerHello+ServerHelloDone which carries the SCSV
> in the ServerHello.cipher_suite = SCSV, which the client will
> recognize and understand as an invitation to send the desired
> full-featured ClientHello (on the very same existing connection
> transparently).

Improving interoperability per se certainly is not a goal of our spec
(instead, it's all about breaking interoperability with attackers if you
will).

That doesn't mean that avoiding the need for fallback retries isn't a
worthy goal, it just is completely orthogonal to what TLS_FALLBACK_SCSV
does. We give you a spec that you can deploy right to gain actual security
advantages (unless your clients never do fallback retries), where the
solution you sketch would be much more involved.

Once anything like what you propose gets successfully rolled out, there
would be no more need to send our SCSV, and the (simple!) server-side logic
would then lie dormant. However I think it's pretty clear that that day is
still pretty far away -- certainly far enough to warrant taking other
measures of protection.

Your claim that TLS_FALLBACK_SCSV
"does not provide any value" appears blatantly untrue, unless you don't
recognize preventing demonstrated attacks as "value".

Bodo