IETF Logo Mail Archive

Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <martin.thomson@gmail.com> Wed, 28 May 2014 20:12 UTC

Return-Path: <martin.thomson@gmail.com>
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 351E91A029F for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 LhhB4BEb5G04 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:12:32 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6951A0051 for <tls@ietf.org>; Wed, 28 May 2014 13:12:32 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so11763094wev.5 for <tls@ietf.org>; Wed, 28 May 2014 13:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zIvfL1LxwNr379SMNDwn3htTDd6levJNPal+TSnEdGc=; b=kDU+w4PuJ+fWhm+XIEYRVYbsTBmsHOyA72NP3n7hgQFDdcH3HsLZCVpQayvgcMaXDu lVoBHQ7j2sonZLFUQOupNz81NG9k5H977ugrgcPJ9VG4Ig82+kTRp7BueO2yV/vUwFo4 +OShGnY9l0dbuEYu0avHdrSi+5DC/Pevm2iJ17vL7Z2GSeCGWG+IMH3SWt3ZNVI+m6aA 3Oghru9Xa6YNbQexIpkIsQGm67TR0foW6bs4++4DnqlQR+k4nD7Sbr9Iu1jhXm/wJTWA WXC2D6xgQ+KnjI3fZHy+NGcyyOaQFMTixZWIdkZWq2gJfVhIUbTOpLmTZagy8QnHvyZQ c/wg==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr52612244wiv.44.1401307947544; Wed, 28 May 2014 13:12:27 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 13:12:27 -0700 (PDT)
In-Reply-To: <53863F1D.3060707@amacapital.net>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> <CABkgnnUrMpmUH7DBgoZUAofe4J6PqNfYn9ORcmwu4385VAUX5g@mail.gmail.com> <53863F1D.3060707@amacapital.net>
Date: Wed, 28 May 2014 13:12:27 -0700
Message-ID: <CABkgnnWCqwVR1TFn8bM5=yNrmYSLMst1r3U_MR5eMD+Dkyv0rg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v4O9-sojhlkfstfjGrAn92moMGA
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 20:12:34 -0000

On 28 May 2014 12:55, Andy Lutomirski <luto@amacapital.net> wrote:
> 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.

The problem with that is that you end up with the keys to the kingdom
just lying around.  And they only seem to exist in order to enable
resumption.  One property I was looking to gain here was the ability
to have a state that cannot be used to derive past states.  Having the
master_secret sitting around loses that.

> 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.

The whole point is to avoid the DH.  The current resumption process
mixes new randoms with the old master_secret.  The old master_secret
is then discarded.  That would seem to have the property you are
looking at.

v2.23.0 | Report a Bug | By Email