Re: [TLS] Key Hierarchy

Hugo Krawczyk <> Tue, 22 September 2015 22:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E99A1B2F03 for <>; Tue, 22 Sep 2015 15:23:19 -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 d_1viY1qNnu4 for <>; Tue, 22 Sep 2015 15:23:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E0611B2F0B for <>; Tue, 22 Sep 2015 15:23:16 -0700 (PDT)
Received: by lahh2 with SMTP id h2so6129160lah.0 for <>; Tue, 22 Sep 2015 15:23:14 -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=69gjgv2SQa0MMFtg+Lw3tdWzTDF0gLgLjadue9a0kec=; b=vUTZByE55kfRa7EDgsW0VDXxu4Cd+QGbwzMglVSnVEwZPtx5EHabuvcRsQvWkSzO/S tuY4h9a036ya05ylXXSyj0rsPjWyWooj88AX0MHLobl8v0Gk4KzZvVL3fwyebBVs25iQ dI4cVguBsRz+SVkEZvZGjtO3KiBNvhxrqPOu9E25c05IK9td+CLRek/X6GFMvtpaLrDJ jn/HZDdkX5P82zG8wtJOB2uvm0kpl7HCvDEKIFBgkNXokEKol+DDLm+n+n7bBg+tM8os UxPRU6NRKzWdU+juHRjSeAbLK1fl7Gu8AYkLBQWn3e1d8nMLj7oePI0oZAZoHfPvCIr1 c/LQ==
X-Received: by with SMTP id uy1mr36128lac.33.1442960594147; Tue, 22 Sep 2015 15:23:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 22 Sep 2015 15:22:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Hugo Krawczyk <>
Date: Tue, 22 Sep 2015 18:22:44 -0400
X-Google-Sender-Auth: WWL_UI12l3oxQRRlmVByOMtJgqw
Message-ID: <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary="001a11340798a39da905205d7160"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Key Hierarchy
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: Tue, 22 Sep 2015 22:23:19 -0000

On Sun, Sep 20, 2015 at 9:56 PM, Brian Smith <> wrote:

> On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla <> wrote:
>> Aside from some analytic advantages
> What are the analytic advantages?

​The advantages are: a cleaner separation of keys derived from ES and SS, a
simpler proof argument (via the explicit functional separation of extract
and expand steps), and the ability to represent the whole key derivation
scheme via the extract/expand steps or via full HKDF calls, whichever is
more convenient (the latter gives significant flexibility to an
implementation depending on its API to the full HKDF function or to its
extract and expand components).

> Also, a question that applied even to the older design: I remember the an
> HKDF paper and the HKDF paper stating that before it is safe to use a value
> as an HKDF salt, it must be authenticated. But, in both the old and new
> designs it seems like an authenticated value is being used as the salt in
> the HKDF-Extract(mSS, mES) operation. What does this mean for the security
> analysis?

​It seems that when you say "an authenticated value" you actually mean "an
unauthenticated value". If I got it wrong let me know.
Assuming this interpretation of your question let me point out that the
value mSS is server-authenticated by virtues of g^s being authenticated
(via a server's signature or a server-configuration​) hence it complies
with the RFC (and paper).

> One of the notes in the new design draws some attention to the strange
> fact that we compress the output of the ECDHE operation to the length of a
> digest function that is independent of the length of the ECDH keys used.
> For example, if we used P-256 in the ECDHE operation for a AES-128-GCM
> cipher suite, we'd compress the output to 256 bits using HKDF-Extract with
> SHA-256. But, if we used P-521 in the ECDHE operation for the same cipher
> suite,  we'd still compress the output to 256 bits using HKDF-Extract with
> SHA-256. That seems wrong. I would guess it makes more sense to choose the
> HKDF digest algorithm based on the size of the ECDHE key. Note that in the
> NSA Suite B Profile for TLS, they fixed this by requiring a more rigid
> relationship between the ECDHE key size and the cipher suite than what TLS
> requires. See [1]. I think it's worth considering whether the current
> (older and newer) design makes is better or worse than a design like the
> NSA Suite B Profile in this respect.

​Ekr answered this. If you still feel something is wrong let us know.


> [1]
> Cheers,
> Brian
> --
> _______________________________________________
> TLS mailing list