Re: [TLS] Computation of static secret in anonymous DH

Hugo Krawczyk <> Fri, 26 June 2015 19:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 826131A8B84 for <>; Fri, 26 Jun 2015 12:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tl48b1-ZSJ0U for <>; Fri, 26 Jun 2015 12:27:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9E501A8AB9 for <>; Fri, 26 Jun 2015 12:27:51 -0700 (PDT)
Received: by lacny3 with SMTP id ny3so69259023lac.3 for <>; Fri, 26 Jun 2015 12:27:50 -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=1B71AthVLQYsMpf6HDBcdvPlEXP0J/W8wQbhnh3WOfU=; b=CZ7BIFVgWTaYreka99eEscXRjO4ekQZq8AICZNPn8rmFUwfIKfArW0JMOCKh69+Ngi yZZFPegWAq0byqqbPmfGu1okOfOGGIGOLKehu6B5AR+i3jzo6rQUmEDZnm32ZDr28aAL Wzh+JVCIBojsNEXegEx4BVXOfI1HW1if0QAwqEJTZTiO3omdN4dOWQEMNsM1XI19Kako TmKFnkSXjGBydHOGjM9zJiomXSkh5gjPyNnsKl6lFMCp88anXUACnzr++OO8voj5mmg6 qmujClSAP7ph26+fuMXWWn/yyEWzMnOhvBhQb4LlszF2u/3SKY4TJBwZr5sj6iSvcAD3 uUDg==
X-Received: by with SMTP id an7mr2987686lbc.103.1435346870251; Fri, 26 Jun 2015 12:27:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Jun 2015 12:27:20 -0700 (PDT)
In-Reply-To: <20150626085008.GA25187@LK-Perkele-VII>
References: <> <20150617082529.GA17280@LK-Perkele-VII> <> <20150617150505.GA19959@LK-Perkele-VII> <> <20150626085008.GA25187@LK-Perkele-VII>
From: Hugo Krawczyk <>
Date: Fri, 26 Jun 2015 12:27:20 -0700
X-Google-Sender-Auth: 47qM5VEDBes4Orn1HErAUlBHKT0
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="001a11c368cc54b525051970bc13"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Computation of static secret in anonymous DH
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: Fri, 26 Jun 2015 19:27:55 -0000

I would prefer to have a more stable version of the draft to comment on
these design choices/logic but let me refer to some of your questions below
(particularly as I  may not be available for responding in the next few

On Fri, Jun 26, 2015 at 1:50 AM, Ilari Liusvaara <> wrote:

> On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote:
> > On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
> >> wrote:
> >
> > > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote:
> > > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> > > >> wrote:
> > > >
> > > > > There's much newer version in ekr/tls13-spec#WIP_draft_06
> > > > > (seems to have fixed most of the mistakes in the original WIP)
> > > > >
> > > >
> > > > Don't worry, I'm sure there are plenty of mistakes left!
> > >
> > > Such as how keys for TLS exporters are derived?
> >
> > Quite possibly. Hence the WIP designation.
> >
> Reviewing it again after changes (e1219310a7f, Jun 25th):
> 1) xSS is used as direct input to HKDF-Expand, so one would presume
> it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand
> are supposed to be paired). HKDF-Extract does not take label nor
> length.

​Logically, xSS is an extracted version of SS and could have been derived
xSS = HKDF-Extract(0,SS)​. Same would apply to xES.
The reason we apply a full HKDF in these derivations (i.e., adding the
Expand part after Extract) is that in cases where SS=ES (e.g. in PSK mode
without PFS) doing just Extract would result in xES=xSS which is bad for
the derivation of master_secret (it would set the seed and key material of
HKDF in the derivation of master_secret to the same value hence requiring
stronger assumptions on HKDF, e.g. being an idealized random oracle).
By running through the additional expand with different labels we get xSS
and xES to be computationally independent (i.e., the outputs of a prf with
the same key but computed on different inputs).

> 2) Same as above for xES.

​Same logic/answer as above.​

> 3) Same as above for master_secret.

​We could have defined
master_secret = HKDF-Extract(xSS, xES)
but we used full HKDF here for uniformity with the derivation of xES and
​lso, in this way we do not have the use of HKDF-Extract in the draft at
all, just full HKDF or HKDF-Expand (the latter being essentially a PRF)
which adds to simplicity.


> 4) Why does master_secret derivation take xSS and xES instead of
> SS and ES directly (especially if xSS and xES are supposed to be
> HKDF-Extract outputs)?

​Since we already extracted the entropy of SS and ES into the keys xSS and
xES it is better to directly use the latter as keys rather than the
non-uniform SS and ES.

> 4) Why is finished independent of ES (IIRC, it did depend on it
> in earlier version)?

Two important reasons.
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 its key share  - deriving the key for the Finished
message calculation from ES would create a circularity issue in the logic
of the derivation.

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
there it makes sense since this comes after authentication and has the goal
of secrecy of the application keys (particularly to resist future attacks
upon compromise of long-term secret keys, namely, when PFS is required).

5) Application data uses xES as secret. AFAICT, leads to an attack.
> Should be master_secret (IIRC, was that way in earlier version)?

​Application data uses master_secret: See table before 7.2.1 where
application keys are derived from MS (should be denoted as master_secret;
the symbol MS is not used anymore)​

> 6) I think the key table should refer to inputs by their proper
> names, not e.g. referring to "xES" as "ES" when there is another
> thing named "ES" (that's confusing even with a note).

​The table is correct by referring to xSS and xES.
These are different values than SS and ES.
As their name indicates they are extracted versions of the latter, hence
stronger for use as keys and for extraction seeds.


> 7) I think there should be helper function defined to do the
> label zero-padding, instead of it being just a note (just for
> clarity).
> -Ilari
> _______________________________________________
> TLS mailing list