IETF Logo Mail Archive

Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt

Eric Rescorla <ekr@networkresonance.com> Fri, 13 November 2009 23:09 UTC

Return-Path: <ekr@networkresonance.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 0406C3A6822 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 15:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.082
X-Spam-Level:
X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
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 6Xg6TW7LjtWp for <tls@core3.amsl.com>; Fri, 13 Nov 2009 15:09:35 -0800 (PST)
Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 22C893A6831 for <tls@ietf.org>; Fri, 13 Nov 2009 15:09:35 -0800 (PST)
Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N95HI-0002Hh-00 for tls@ietf.org; Sat, 14 Nov 2009 01:10:04 +0200
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 5AFFE69F517; Sat, 14 Nov 2009 01:11:10 +0200 (EET)
Date: Sat, 14 Nov 2009 01:11:10 +0200
From: Eric Rescorla <ekr@networkresonance.com>
To: Robert Dugal <rdugal@certicom.com>
In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net>
References: <7E1DF37F1F42AB4E877E492C308E6AC402430344@XCH57YKF.rim.net>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091113231110.5AFFE69F517@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] client and server verify_data in draft-rescorla-tls-renegotiate.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 13 Nov 2009 23:09:36 -0000

At Fri, 13 Nov 2009 14:28:53 -0500,
Robert Dugal wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> A co-worker an I have been discussing the draft and have some concerns
> about sending client and server verify_data in the extension.
> 
> In the ClientHello, the client sends the verify_data from the client's
> previous Finish message as the renegotiated_connection data.
> 
> In the ServerHello, the server sends both the cient's verify_data and
> the server's verify_data.
> 
> This data is not normally sent in the clear and I am wondering if this
> will provide additional data that can be used to mount some other form
> of attack .

But they're not being sent in the clear here either. They're being
sent over the same encrypted channel that they were originally sent
over. Remember that you're renegotiating over an existing TLS
channel.


-Ekr

v2.23.0 | Report a Bug | By Email