IETF Logo Mail Archive

Re: [TLS] Proposed text for removing renegotiation

Eric Rescorla <ekr@rtfm.com> Wed, 28 May 2014 20:15 UTC

Return-Path: <ekr@rtfm.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 E80091A0417 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 GZcVuXzHfsAA for <tls@ietfa.amsl.com>; Wed, 28 May 2014 13:15:58 -0700 (PDT)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CFF1A0051 for <tls@ietf.org>; Wed, 28 May 2014 13:15:57 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id n12so11811204wgh.5 for <tls@ietf.org>; Wed, 28 May 2014 13:15:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mVHSqVi/5xK56tVEsAm2AFeEsaNFnKeqGY8sLbvwun0=; b=cGWvtyAimax1CbXEpt3CRSWf3gg/NUpZybV7K1XgHWR0oDLqPqNh6RjA/RJUOOK8if iWtSnVEZQuy2ywkM602qaOakJWN178QTguNIf+lAv+MIpZ1lB5m9tdG4ozWNLIsgvn6x nUzgIXNYCSQDO5PfNuqqgdTc4C0K8wLfc2PIHRSVurnjF41bI9jD0VeNwby8YCyBEMoH cUyFx8R75swMS4NsbhEn7jh4qhYmijERwbZ2bZvWTNXNkMheEsuxA4nzO02uRcnrFoYX orEHN8S5kgjO0SjPMP3LjINZ/VwFc3ue7FR5n4ppZtLoqod/lWkkR+UEmPbyr5mE+Lvo 5zHQ==
X-Gm-Message-State: ALoCoQm3FJFWgyT1c/eUfebDcPU6i3iqvLd7EAZwp0L2+b9BdIsd2ErTKe2AnAeNQlcXETnxLeCl
X-Received: by 10.194.62.176 with SMTP id z16mr2939514wjr.76.1401308152877; Wed, 28 May 2014 13:15:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Wed, 28 May 2014 13:15:12 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:7931:db29:b29d:2f29]
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 28 May 2014 13:15:12 -0700
Message-ID: <CABcZeBNShZsKvMWKPiTpCP6rB6keemZFuhXQZgYCT7R=wJCgHg@mail.gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: multipart/alternative; boundary="047d7ba979c2ac6e4204fa7b7aa9"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/me6pNhw2XAP2PdjDG48z_2F9Kwc
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:16:00 -0000

On Wed, May 28, 2014 at 12:55 PM, Andy Lutomirski <luto@amacapital.net>wrote:

> 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 seems like it would seriously decrease the value of resumption.

-Ekr




>
> --Andy
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email