Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)

Eric Rescorla <> Mon, 20 July 2015 07:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D69161A00DD for <>; Mon, 20 Jul 2015 00:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N1W_1qGtSsFI for <>; Mon, 20 Jul 2015 00:11:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AB491A00BB for <>; Mon, 20 Jul 2015 00:11:23 -0700 (PDT)
Received: by wicmv11 with SMTP id mv11so7502077wic.0 for <>; Mon, 20 Jul 2015 00:11:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DHVbOdgoe/dbtM2WhliMgyaIKLsB9ww9B/tlDvfBst4=; b=fupneafuNPVvvUEr9zr8HDhTc0cDH+Bri7dTkb4DwClBDD6CZOKsbzJZdlzosuEWZ+ 2P/ZWF53K8hhQ4P84ZYDxImBR0EgRHxfLUmoQsO/Y7JbAVkrgEXE7rLHmrhr1NpLF232 em/O7j/TXKen4eQ2cOo/RZcEjTrdJ684v0VZyLa/0j6xG/LLZEmtx/D3sJhvx7aoXOS/ LGqtUjPf4fX1NvMMY6n0vkJspSrjHQNMRAxfxPzxbU4bjUGX8k1gROH1JH5pT9yyjzAJ C2+0MBPXVQyAbRyfHLw5F6/+EaZlJ98WF4d+DV9Xe/AvpywBcH4q3dw+HA6imZ/Idi1p I/7w==
X-Gm-Message-State: ALoCoQliaFsXT+eW37AEoN8cczz42+3rk7kkaq+444pT6rTC4PFDV8J6AMd/mraC0OgxlmjxhGAn
X-Received: by with SMTP id m1mr54454476wjx.8.1437376282019; Mon, 20 Jul 2015 00:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jul 2015 00:10:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 20 Jul 2015 09:10:42 +0200
Message-ID: <>
To: Dave Garrett <>
Content-Type: multipart/alternative; boundary="047d7b10c903b36745051b493e5c"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)
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: Mon, 20 Jul 2015 07:11:26 -0000

On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <>

> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> > I think perhaps you have misunderstood the forward secrecy properties of
> the
> > current draft. Unlike TLS 1.2 and previous, the current draft has a
> separate
> > resumption master secret which is independently derived from the master
> > secret used for the connection keys in the original connection. This
> means
> > that if you don't resume the connection, you have forward secrecy for the
> > original connection regardless of whether the server stores the session
> in
> > the session cache or sends the client a ticket.
> We've got lots of keys and secrets now. Could you please clarify the exact
> points where these are each to be discarded? If I am understanding it
> correctly, the master_secret, prior intermediate secrets, and
> finished_secret are to be discarded as soon as the keys, resumption_secret,
> and possibly exporter_secret (which currently has no explanation in the
> doc) are derived, the handshake is finished, and we're ready for
> application traffic? It would help if you provided a table/chart laying out
> the timeline of secret & key lifetimes, from derivation to discard. It
> should state in the spec explicitly what needs to be kept around for how
> long and require things be discarded as soon as viable.

Yes, I can do something along these lines.

> I think these various values need to be named more consistently in the doc
> to make searching for them easier. For example, "resumption_secret" is used
> in the computation part but the words "resumption master secret" are used
> when actually using this value. (also noted in issue #191 by Martin
> Thomson) I've pushed a small PR to correct this case along with a few
> tweaks that I think makes it a bit clearer.
> Also, some other questions about various computations:
> HKDF(,,,) doesn't seem to be fully defined here, just
> HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869.
> Could you please clarify this?


> Why is finished_secret derived from extracted static secret instead of
> master_secret?

The rationale here is that the Finished message also serves to authenticate
the server's ephemeral DH share (when in known_configuration mode) and
because the master secret depends on the ephemeral DH keys, this creates
an odd authentication logic. Hugo can expand on this some more, perhaps.

> Are there two finished_secret in the event that the client sends a
> certificate?

No, this shouldn't be necessarily. You just use the first one. I'll try to

> The computation of verify_data could probably be moved up to the same
> section so this is all in the same place. Am I correct in reading that it
> could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret,
> finished_label, handshake_hash, L) without the extra HMAC currently defined
> for verify_data)

See above.