Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

mrex@sap.com (Martin Rex) Mon, 27 January 2014 15:30 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 4BA131A02D9 for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 07:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k9tr2KC5Yg2j for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 07:30:18 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB91A029B for <tls@ietf.org>; Mon, 27 Jan 2014 07:29:58 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0RFTu27020432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jan 2014 16:29:56 +0100 (MET)
In-Reply-To: <BLU0-SMTP1738DF906BCBD666044DA2AB1A30@phx.gbl>
To: Yoav Nir <synp71@live.com>
Date: Mon, 27 Jan 2014 16:29:56 +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: <20140127152956.460001ABC9@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
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: Mon, 27 Jan 2014 15:30:23 -0000

Yoav Nir wrote:
> 
> I'm not opposed to this document, but we should be realistic as to what 
> this solution can accomplish.
> 
> Also, older servers will not recognize the SCSV and ignore it. So to 
> have this extension add any value, all of the following much be true:
>   - an updated server
>   - an updated client
>   - Something that causes the negotiation to fail. This something could 
> be the client, the server, or something in between. The goal of this 
> extension is to catch the something in the middle.

You're missing an even more important pre-requisite.

This SCSV will only provide any value for application clients that are
actually implementing a reconnect fallback logic at the application
level.  A fallback reconnect can not be transparently implemented
by a TLS implementation, because it requires a seperate and new connection
to be established, and any application-level protocol handshakes
(such as a HTTP CONNECT proxy traversal or the application protocol
exhanges that happen before and include "STARTTLS".

The vast majority of programmatic TLS clients does still does not have
any reconnect fallback logic, and would have zero benefits from this
proposal.

A modified extension that allows the server to continue the handshake
with a TLSv1.2 ServerHello, could be processed transparently within
the TLS client implementation and provide immediate benefits to TLS clients
that do not have any application-level reconnect fallback.


What you also have to keep in mind is that the reconnect fallback that
has been implemented&shipped was quite brittle/flaky, and reconnect
fallbacks often happen unnecessarily because of bugs in the clients
connection handling (keep in mind that this is app-level reconnect
fallback logic, since this can not be transparently hidden within TLS):

  https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c3


I know that Microsoft Internet Explorer has similar problems in its
client-side app-level connection state handling, which can already cause
connection failures (and white pages/frames).


-Martin