Re: [TLS] Redefine Finished message for TLS 1.3 ?

Martin Rex <mrex@sap.com> Sun, 15 November 2009 02:30 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 C9CA33A6784 for <tls@core3.amsl.com>; Sat, 14 Nov 2009 18:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.177
X-Spam-Level:
X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 tQ9vkIe+gU4o for <tls@core3.amsl.com>; Sat, 14 Nov 2009 18:30:03 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A26AF3A6359 for <tls@ietf.org>; Sat, 14 Nov 2009 18:30:02 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAF2UTt3023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 03:30:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911150230.nAF2USpK019975@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Sun, 15 Nov 2009 03:30:28 +0100
In-Reply-To: <4AFF0153.3090005@bolyard.me> from "Nelson B Bolyard" at Nov 14, 9 11:13:23 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] Redefine Finished message for TLS 1.3 ?
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: Sun, 15 Nov 2009 02:30:03 -0000

Nelson B Bolyard wrote:
> 
> I proposed that a change in the computation of the TLS Finished message
> to include some value derived from the master secret previously in use on
> the connection before the current renegotiation (such as the Finished
> message contents or some other value "extracted" from the master secret)
> would avoid the overhead of the new extensions on the wire.  My goal was
> to avoid the extra bandwidth and memory cost of those extensions, which
> might be deemed too costly in certain low memory or bandwidth constrained
> applications.
> 
> Others in the meeting responded that changing the definition of the
> computation of the Finished messages was a change to the base protocol
> specification (which adding an extension is not), and thus the change
> I proposed would make TLS become (say) TLS 1.3.

Well, we have a security flaw in the base spec, specifically in the
computation of the Finished messages for the TLS renegotiation, because
it fails to provide a cryptographic binding to the session that is
replaced.

The correct approach to fix a defect in the base protocol is, of course,
to fix the base protocol.  The defect is specific to the TLS renegotiation
and is so severe, that the IETF ought to strongly discourage any future
use of the defective protocol feature.  The negotiation will provide
sufficient information to vendors and implementors to decide on their
own whether and when to still support the defective protocol feature.


TLS extensions are fairly new, cause interop problems and are purely
optional protocol features.  TLS extensions are _not_ part of the base
spec of SSLv3, TLSv1.0 and TLSv1.1.  

The fix for this defect in the TLS renegotiation should be as close to
mandatory as it can be and for all implementations of SSL/TLS independent
of their protocol levels (SSLv3,TLSv1.0,TLSv1.1,TLSv1.2).

The more I think about it, the more I'm opposed to using
TLS extensions to wrap this fix.  It's just to urgent and serious
to spend such an amount of time on a fancy wrapping.

-Martin