Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Martin Rex <mrex@sap.com> Thu, 26 November 2009 05:46 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 D9D9B3A6B54 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 21:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.181
X-Spam-Level:
X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 c8xVGp+sKdqc for <tls@core3.amsl.com>; Wed, 25 Nov 2009 21:46:11 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2DA5F3A68AC for <tls@ietf.org>; Wed, 25 Nov 2009 21:46:09 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ5k26J025592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 06:46:02 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911260546.nAQ5k2Rt027106@fs4113.wdf.sap.corp>
To: david-sarah@jacaranda.org
Date: Thu, 26 Nov 2009 06:46:02 +0100
In-Reply-To: <4B0E1399.8030303@jacaranda.org> from "David-Sarah Hopwood" at Nov 26, 9 05:35:21 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] Quest for Unified Solution to TLS Renegotiation
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: Thu, 26 Nov 2009 05:46:11 -0000

David-Sarah Hopwood wrote:
> 
> This approach and RI have different security properties: because RI
> does not change the Finished computation, it relies on the recipient
> of the extension checking that its contents are correct.
> 
> OTOH, I think it's only necessary for the previous verify_data to
> be sent once. So, how about sending that only in the ServerHello, i.e.

That is MUCH worse.

Normally the TLS handshake is symmetric, each one proves each other
(like with the Finished messages).

Client re-sending Client.Finished and Server re-sending Server.Finished
would still be symmetric (and both need to check).

If only one side sends and the other must check, then this is
asymmetric, and if the one side that is supposed to check
forgets it, then you have a security problem.

When each one resends. then both must forget to check to
make that security problem.

-Martin