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

mrex@sap.com (Martin Rex) Wed, 29 October 2014 02:35 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 03EDB1A1BA5 for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 19:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 opE9XgAxBzAT for <tls@ietfa.amsl.com>; Tue, 28 Oct 2014 19:35:31 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468191A6EE7 for <tls@ietf.org>; Tue, 28 Oct 2014 19:35:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 060F36A9F0; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id BB790443B2; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B14E71AF5F; Wed, 29 Oct 2014 03:35:28 +0100 (CET)
In-Reply-To: <544E9A42.9080503@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 29 Oct 2014 03:35:28 +0100
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: <20141029023528.B14E71AF5F@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-YA-owgWI1_urpiHv_n1VO9Ox5s
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
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: Wed, 29 Oct 2014 02:35:34 -0000

Daniel Kahn Gillmor wrote:
> 
> The failed handshakes associated with false positive fallback behavior
> are from network glitches, right?  not from poorly-implemented or
> unmaintained servers.

As you can see from 5-years-unfixed annoying broken connection management
in Firefox you should be able to see that a huge amount of problems
of false positives come from poor connection management and poor
heuristics, and some from middlelboxes.  network glitches are probably
quite rare.


> 
> in the face of a network glitch, user agents have three options (browser
> behavior in parens):
> 
>  0) report the connection failure up the stack (browsers: show the user
> the "try again button")
> 
>  1) automatically try the connection again, same as last time
> 
>  2) try the connection again with a fallback handshake
> 
> 
> 
> in the false positive cases that we're discussing here, (1) is probably
> the best option.  doing (2) leads directly to choosing a degraded
> ciphersuite.
> 
> including the SCSV with (2) gives the client an inappropriate_fallback
> alert, which they can use to recognize the false positive situation and
> do (1) instead.


This is a misunderstanding.  You may see much less of the
inappropriate_fallback alerts that you might believe you would.

Apps on top of transport-less SSL implementations, such as
Microsoft's IIS on top of Microsoft SChannel SSP has historically never
written any fatal alerts (from the SChannel SSP) to the network
before closing the connection upon handshake failures.

I don't know what the current state is, but if this behaviour is still
common with Micrsoft IIS, then asking the server to abort with
a fatal alert rather then continuing the handshake with a
ServerHelloExtension might have *MUCH* less of a chance to get
hotfixed into the installed base compared to purely TLS-internal
(i.e. SChannel-only) change similar to Renego-protection,
where the server continues the Handshake (provided that the negotiable
security parameters are still acceptable to the servers own policy),
leaving the decision whether to abort and reconnect up to the client
--because only the client is in the position to perform a reconnect,
and only the client has a chance to keep track on whether and how
often it is doing fallbacks and whether the fallback frequency crosses
some threshold that should not be exceeded without prior explicit
user confirmation.

Continuing the handshake would not require any app-level changes to Servers
that have not been writing fatal SSL alerts to the network before 
connection closure in the past, such as Microsoft IIS, so clients
with fallback heuristics will be in a *MUCH* better position to
recognize and distinguish accidental network glitches or connection
management bugs from attacks.  I expect the false positives to
outnumber attacks by at least three orders of magnitudes.


-Martin