Re: [TLS] Proposed text for removing renegotiation

Andy Lutomirski <> Wed, 28 May 2014 19:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 506441A068B for <>; Wed, 28 May 2014 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F7HfJJctx9L4 for <>; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20C3D1A0386 for <>; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: by with SMTP id rp16so11723455pbb.20 for <>; Wed, 28 May 2014 12:55:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jrf1pn0eZe3CW0c7b/rhQEP+ysJn6kBTm4eYnXtcHqs=; b=ih9g/B3ZcGd40lApfS2HAQzxm3b1AVdRdArYnl+fqBiAJ1UviSc8nmgXZYDwpB9cKZ /pw29RfwOW8v3h7bfcataLULdz/WEWSt6as5DUYKskYEwyOSokNPd28SDsXZIIb1E8Ua P7pZxp2Q7ynCxHs8R/Ix7jWUfj5xwHyeQl429oKSiCD6rtbYTH9qX/8WJp/titlFxEuA Zy4MA9SeuhYAUZNjaTQ6o9j5qo1AbkPiJOL1XdyeX9GuVGSK+txoc8Wmg+94W58//ahl 3QlMgQcrW4tWBXrBgbzXB9cEzOlycG8BjabF/DaM6kanj3jDD5cQRtcHT+paOealY5WR pDLw==
X-Gm-Message-State: ALoCoQmvhKlW97yUkrgVmHFVgMgtX5FDUvOLgJ1gAv25Ylt/iNoYAvWw3OZL+EY0pf949vgPlvV3
X-Received: by with SMTP id qt3mr2631719pbb.6.1401306911573; Wed, 28 May 2014 12:55:11 -0700 (PDT)
Received: from ( []) by with ESMTPSA id ec2sm29737801pbc.63.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 12:55:10 -0700 (PDT)
Message-ID: <>
Date: Wed, 28 May 2014 12:55:09 -0700
From: Andy Lutomirski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Martin Thomson <>,
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-Mailman-Version: 2.1.15
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: Wed, 28 May 2014 19:55:16 -0000

On 05/28/2014 10:02 AM, Martin Thomson wrote:
> On 27 May 2014 17:44, Martin Rex <> wrote:
>> Conceptually, the TLS session cache is readonly after an entry
>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>> distict session cache entries, and abbreviated TLS handshakes resume
>> existing session cache entries and *NEVER* modify them.
> That's a good point.  Something that I missed.  A resumption handshake
> would have to include an epoch from the previous session.  That number
> would need to be incremented with each update of the master secret.

Rather than mucking with the master secret, can't we rearrange the key
hierarchy a bit:

Separately derive master_secret and temporary_secret from
premaster_secret.  Use master_secret as it's currently used for
resumption, but use temporary_secret for encryption and MAC.  When it's
time to rekey, roll over the temporary_secret but leave the
master_secret alone.

Getting resumption right might be a little tricky here: unless a new DH
exchange happens on resumption, the new temporary_secret will have to be
derived from master_secret.

This gets another benefit for free: a compromise of the session cache or
the ticket key doesn't compromise old non-resumed connections.