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

Hugo Krawczyk <> Mon, 20 July 2015 17:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A84BB1B2D0C for <>; Mon, 20 Jul 2015 10:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M7tGmBtqVjiI for <>; Mon, 20 Jul 2015 10:32:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 287EC1B2CFB for <>; Mon, 20 Jul 2015 10:31:46 -0700 (PDT)
Received: by lbbqi7 with SMTP id qi7so19281899lbb.3 for <>; Mon, 20 Jul 2015 10:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lzcknb6o2reaCc0tkoOY9OPQLtsqOgUNTazBr9SGNEw=; b=hzUdzxR3bh59aZ1vEmRFir6sTJNo0vdrJMeM+VrXxujKtIU7FyDabuMUnl+nudyOQe v8z01KY+DUs8dfMrw0Q5pHjdMgZm1XT2pR248+XySvv38TiFXjfVdfVcnSPdmzKfKGZR Y5Rr4p9+yn9Ilx3PwSJLtguCvn6BTmzoABKyDTAIxnpD2sU5miAvYQHOhQXbIn3RZLva AflKoggAlNDfPWJT0r55UQ5kKt9YHZ/Ab4Dmw6zUnaIaVR9K9P9oqXInZT7iStvN3LHM raROAKh+1L8v1eRjbUJvvpBr849U5JLE0EoRq0Zq1r7qHYYLk412u32sHEzVXdTjArrg ysSg==
X-Received: by with SMTP id n9mr28905771laj.79.1437413504590; Mon, 20 Jul 2015 10:31:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jul 2015 10:31:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Mon, 20 Jul 2015 10:31:15 -0700
X-Google-Sender-Auth: ORxqL8LbLngZfAWt9n6BM40s2NE
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=089e0158b608562a81051b51e9a9
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 17:32:06 -0000


On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla <> wrote:

> On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <>
> wrote:
>> 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?
> Yes.
>> 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.

​Eric's explanation is correct.
Your question boils down to: Why is finished_secret derived from SS only
and not from ES?

First note that the issue only arises in the known_configuration case since
in other cases ES and SS are the same.
For the known_configuration case there are t
wo important reasons
​ to build on SS and not on ES:
1. Only SS can authenticate the handshake as it is the only element to
involve the server's (semi) static private key.
2. One of the main elements to be authenticated by the server (via the
Finished message) is the ServerKeyShare, thus deriving the key for the
Finished message (i.e. finished_secret) from ES (calculated using
ServerKeyShare) would create a circularity issue in the logic of the

Note that the derivation of application keys (and other key material
remaining after the end of the handshake) do involve both SS and ES, but in
that case involving ES is crucial to achieve forward secrecy.


>> 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
> clarify.
>> 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.
> -ekr
> _______________________________________________
> TLS mailing list