Re: [TLS] Key Hierarchy

Eric Rescorla <> Mon, 21 September 2015 03:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A78741A212A for <>; Sun, 20 Sep 2015 20:03:42 -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 p9lhcVFjNfrd for <>; Sun, 20 Sep 2015 20:03:41 -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 A944A1A1F70 for <>; Sun, 20 Sep 2015 20:03:40 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so126848505wic.1 for <>; Sun, 20 Sep 2015 20:03:39 -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=OyWq7d0KpEMtDppYlM+0oIvNgCczmgpA0qp+Ww7mXQ0=; b=EuJ4gHo/vLooPw6up7SAQTqubbxW5grKlQI5A+ra1+iRfc5GJpCTaNSUgll8WRVd8l RiNG9vMRoraKuABh+weSIoKlUY9cj472uAKWVWIbA4gxmjcn/sPcxRnoRxszMsS8UDs3 NHp7X7cyATTaF5Ho4KzH5ZAByfvS3VvVEcI5nCWni6n7ptE5y0jb/BcxiEpe0avavuBH 0UbuPedIV6Z00uxzJ+AdRw5y1R6V4eFxX46hyVwa4rvTpNS+Aot4Rqlkthuy9OxnHmZd VvFYaCtr37T1pBs7W6cide0PwLZKLpqFZOG/dIg1GMkbBOS+gD5i9b0w8uOdMGxVRbnc cI2g==
X-Gm-Message-State: ALoCoQnBfabghNcKDBfjIjEmr6VV7N6ydEW4hP93f1QofhMUyCa/3zK+rOAtOt5d4ICVWdK2V6us
X-Received: by with SMTP id h17mr966629wjs.8.1442804619290; Sun, 20 Sep 2015 20:03:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 20 Sep 2015 20:02:59 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Sun, 20 Sep 2015 20:02:59 -0700
Message-ID: <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary="047d7ba97418d04389052039205f"
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: Mon, 21 Sep 2015 03:03:42 -0000

On Sun, Sep 20, 2015 at 6: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?

As I said, a clearer separation between the input keying material
used to make traffic keys and that used to make keys which
are then input into HKDF.

> 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?

I'm going to defer this to Hugo and Hoeteck.

> 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.

Why? Note that the next thing we are going to do is use this keys to
keys which are generally <= 256-bits.

It's also worth noting that previous versions of TLS behaved this way as