Re: [TLS] Black hole was Re: Analysis of Interop scenarios TLS

Martin Rex <mrex@sap.com> Mon, 14 December 2009 15:54 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3ACA3A6881 for <tls@core3.amsl.com>; Mon, 14 Dec 2009 07:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level:
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpPTi+cOhfUR for <tls@core3.amsl.com>; Mon, 14 Dec 2009 07:54:44 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DE7763A67EB for <tls@ietf.org>; Mon, 14 Dec 2009 07:54:43 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBEFsPA9015313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 16:54:25 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912141554.nBEFsODa002884@fs4113.wdf.sap.corp>
To: cfinss@dial.pipex.com
Date: Mon, 14 Dec 2009 16:54:24 +0100
In-Reply-To: <001801ca7bda$3492bfc0$0601a8c0@allison> from "tom.petch" at Dec 13, 9 10:43:00 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Black hole was Re: Analysis of Interop scenarios TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 14 Dec 2009 15:54:45 -0000

tom.petch wrote:
> 
> There is a solution.  We should require, as part of this patch, that upgraded
> stacks treat a version number that is greater than some specified value as
> also being a signal that the peer is upgraded.  Then we will be able to drop
> the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need
> to include this now.

In theory, you are correct.

This would, however, require us to effectively standarize the secure
TLS renegotiation for TLSv1.3 (or some specific TLS version in the future)
ahead of time.  

The decision for the server would be easy, since it knows both protocol
version values (the ClientHello.client_version and his own max. supported
value) after processing ClientHello.  The decision for the client is
more difficult on the initial connect, when it doesn't know yet
whether the server will understand it, and this problem remains
on the renegotiation handshake, where an MitM attacker might proxy
the renegotiation handshake into an initial or renegotiation handshake
of an older server.

One could define my draft-mrex-tls-secure-renegotiation-03 to become
standard with TLSv1.3 and have it grow out of the installed base
naturally, because it changes the handshake message hash, and
prevents you from proxying a new (both initial and renegotiation) handshake
from proxying into handshakes of old servers.

TLS extension RI, on the other hand, does _not_ change the handshake
message hash, so you will have to keep that band-aid around for as long
as you _allow_ interop with TLSv1.2 or below, no matter what TLS WG
defines and implements in newer protocol versions.  Therefore
TLS extension RI is tomorrows cruft.


-Martin