Return-Path: 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 ; 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 ; 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 ; Wed, 28 May 2014 13:15:57 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so11811204wgh.5 for ; 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: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> <53863F1D.3060707@amacapital.net> From: Eric Rescorla Date: Wed, 28 May 2014 13:15:12 -0700 Message-ID: To: Andy Lutomirski Content-Type: multipart/alternative; boundary=047d7ba979c2ac6e4204fa7b7aa9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/me6pNhw2XAP2PdjDG48z_2F9Kwc Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:16:00 -0000 --047d7ba979c2ac6e4204fa7b7aa9 Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 12:55 PM, Andy Lutomirski wrote: > 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 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 > --047d7ba979c2ac6e4204fa7b7aa9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 12:55 PM, Andy Lutomirski <luto@amacapit= al.net> wrote:
On 05/28/2014 10:02 AM, Mart= in Thomson wrote:
> On 27 May 2014 17:44, Martin Rex <m= rex@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 resu= me
>> existing session cache entries and *NEVER* modify them.
>
> That's a good point. =C2=A0Something that I missed. =C2=A0A resump= tion handshake
> would have to include an epoch from the previous session. =C2=A0That n= umber
> would need to be incremented with each update of the master secret.
Rather than mucking with the master secret, can't we rearrange th= e key
hierarchy a bit:

Separately derive master_secret and temporary_secret from
premaster_secret. =C2=A0Use master_secret as it's currently used for resumption, but use temporary_secret for encryption and MAC. =C2=A0When it&= #39;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
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7ba979c2ac6e4204fa7b7aa9--