Re: [TLS] TLS Digest, Vol 65, Issue 86

Michael D'Errico <> Sun, 20 December 2009 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12AC83A6984 for <>; Sat, 19 Dec 2009 18:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9WuEkdxZkiqq for <>; Sat, 19 Dec 2009 18:47:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 28AE43A6801 for <>; Sat, 19 Dec 2009 18:47:50 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 01155A853D for <>; Sat, 19 Dec 2009 21:47:35 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=62pExSqg1gTV RNfTA8djJQ55VUU=; b=GoECFV65wJKf72/2l0/efdm17tal6pbUjZXwtJot1an9 OvBIyMDIc7C2k56yBUTlGESDyI2fhIlUYiP9A9Qxzvih5RRyKsjEtt1YJYIQbaBO Vx2k/fVVMVd0y9ZKeOI7OQrHUoaAl5KyIXH7oUZyr7wLRn/m11pu2BjxHP7bAhc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=riKg9o HLwofVISxHtUi0knjgNCIk9fdH2wIiYpRlmIdyHhxirU3Wxr9MWwQdnmuejAxkmv 9TubUsWv2ND3i/yZkY+32QuorAUgZec5csNLYUa9rUQDmY+ZnJN7he9gzpKj+0X4 4Rus8Ue1ssreieTDmPmY2sO7NKA+2+TZk9D8w=
Received: from (unknown []) by (Postfix) with ESMTP id F241FA853C for <>; Sat, 19 Dec 2009 21:47:34 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9D19CA853B for <>; Sat, 19 Dec 2009 21:47:34 -0500 (EST)
Message-ID: <>
Date: Sat, 19 Dec 2009 18:49:30 -0800
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 06F3CCEA-ED12-11DE-AC1A-B34DBBB5EC2E-38729857!
Subject: Re: [TLS] TLS Digest, Vol 65, Issue 86
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Dec 2009 02:47:53 -0000

Ravi Ganesan wrote:
> ....  If by renegotiation one means "brand new keying 
> material"  then the abbreviated handshake does not achieve it, as there 
> is no new master_secret.

A renegotiation is a _handshake_ that occurs after the initial handshake.

First, you perform an initial handshake to establish a secure channel.
Then if you ever perform a handshake over this previously-established
secure channel, you are renegotiating.

The initial handshake may be full or abbreviated, and the renegotiation
may be full or abbreviated.  TLS does not require the renegotiation
handshake to be related in any way to the initial handshake (except now
we are adding the Renegotiation_Info extension to prevent man-in-the-
middle attacks).

A full handshake creates a new master secret and an abbreviated handshake
reuses one.  All handshakes generate new keying material based on the
master secret.