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

mrex@sap.com (Martin Rex) Fri, 06 December 2013 18:25 UTC

Return-Path: <mrex@sap.com>
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 6B6601ADEB4 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 10:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.152
X-Spam-Level:
X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 l3DsNgqaSGDD for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 10:25:35 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CF26A1AD8F9 for <tls@ietf.org>; Fri, 6 Dec 2013 10:25:34 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB6IPRZn011728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Dec 2013 19:25:27 +0100 (MET)
In-Reply-To: <CADMpkcKGs_=Skd2_NzdyNvQB2WachTtBGNPx+5QHxwRhQ7Ln_w@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Fri, 6 Dec 2013 19:25:27 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 06 Dec 2013 18:25:37 -0000

Bodo Moeller wrote:
> 
> 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).

Huh?  Your proposal is not going to improve the security one single bit.

Either the handshake goes through as initially proposed
(no TLS_FALLBACK_SCSV present in ClientHello), and therefore there can
not possibly be any improvement (or any effect).

Or the client's heuristics on network connectivity or handshake failure
from a connection attempt will result in an app-level reconnect fallback
to kick in and a new connection attempt with a more conservative ClientHello
with TLS_FALLBACK_SCSV asserted.  Either that handshake will succeed
as proposed (as if TLS_FALLBACK_SCSV wasn't present), or the handshake
will fail.

So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
of the TLS protocol not at all, or cause a fatal handshake failure.
And very few, if any at all, of the situations where the handshake fails,
will be instances of an active attack.  And it remains extremely
questionable, when the handshake would succeed, that the attacker
will gain anything at all.


I really do not see any benefit for servers to adopt support for this
interoperability problem.


For this feature to work at all, the prerequisite is that both communication
peers must be updated.  When looking at a protocol feature that requires
both communication peers to be updated as a prerequisite, wouldn't it be
preferable to fix those protocol features of SSL/TLS that we deem necessary
for reliable security to become negotiable even in the "most conservative"
ClientHello that clients are willing to fallback to?  This would make
the TLS handshake immune to "version downgrade" attacks  and allow
programmatic clients to offer TLS features (and cipher suites) that are
artificially and needlessly curtailed to the TLSv1.2 version number right
now to be negotiatiable in conservative ClientHellos.
This would completely obviate the fragile and complex app-level reconnect
fallback logic that is currently necessary to cope with failed TLS
handshakes caused by version-intolerant servers and dense middle boxes.


-Martin