Re: [TLS] Proposed text for removing renegotiation

Andy Lutomirski <luto@amacapital.net> Wed, 28 May 2014 19:55 UTC

Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506441A068B for <tls@ietfa.amsl.com>; Wed, 28 May 2014 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7HfJJctx9L4 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C3D1A0386 for <tls@ietf.org>; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rp16so11723455pbb.20 for <tls@ietf.org>; Wed, 28 May 2014 12:55:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.68.138.227 with SMTP id qt3mr2631719pbb.6.1401306911573; Wed, 28 May 2014 12:55:11 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ec2sm29737801pbc.63.2014.05.28.12.55.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 12:55:10 -0700 (PDT)
Message-ID: <53863F1D.3060707@amacapital.net>
Date: Wed, 28 May 2014 12:55:09 -0700
From: Andy Lutomirski <luto@amacapital.net>
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 <martin.thomson@gmail.com>, mrex@sap.com
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> <CABkgnnUrMpmUH7DBgoZUAofe4J6PqNfYn9ORcmwu4385VAUX5g@mail.gmail.com>
In-Reply-To: <CABkgnnUrMpmUH7DBgoZUAofe4J6PqNfYn9ORcmwu4385VAUX5g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HkVAytuNaVLRQT9o75jX39T9hlo
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: 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 <mrex@sap.com> 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.


--Andy