Re: [TLS] Key Hierarchy

Brian Smith <> Mon, 21 September 2015 01:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 610461B2F6C for <>; Sun, 20 Sep 2015 18:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xh9ARZfhfmnD for <>; Sun, 20 Sep 2015 18:56:45 -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 87CB81B2F6B for <>; Sun, 20 Sep 2015 18:56:45 -0700 (PDT)
Received: by igcrk20 with SMTP id rk20so51270072igc.1 for <>; Sun, 20 Sep 2015 18:56:45 -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:date :message-id:subject:from:to:cc:content-type; bh=WPmCq0GYNXsv/TlhXvELBjFUxkjF3aVsB6meNmqmM1s=; b=UXeDRPZi6aRLLzPHoVKUHu9lLo+wUC4lmog2fCKiT+22xXe+3WFNmDDjAD+tY15vAW VyCaSToawMN8QtPlbAZ6fp7pS0ypWgt/bJk6yU6EdaHx9kPGSq3MEM+hhutpKhnVmsLl ZJ20XETeJxyPPM8rhJD5d6qbGOn1KNgk5vg8g97apr0+cYxdEhZA6pkew9wLY3oeHBKX IjoWBGgBtRbNcsGf5Wy2lAEQu4D3wpPn4/w68CbFqk53B2Nrxe1j8L75DcGusyN92jRe TGCL99vGoJc5OA5bXEDd/dIyguG+dQTRhuCWc96t2k5/jFsV2KddKeY00iNHZbXiRrJY cJwQ==
X-Gm-Message-State: ALoCoQkFnmVJAJr+VV7855Xy9sHlcKs890PZDW1EEVAk1xnaWqfbyoX9au0forw9mNE5j6tigsIs
MIME-Version: 1.0
X-Received: by with SMTP id sa1mr8973491igb.32.1442800604832; Sun, 20 Sep 2015 18:56:44 -0700 (PDT)
Received: by with HTTP; Sun, 20 Sep 2015 18:56:44 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sun, 20 Sep 2015 18:56:44 -0700
Message-ID: <>
From: Brian Smith <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a1134bdaa88847105203831a0"
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 01:56:47 -0000

On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla <> wrote:

> Aside from some analytic advantages

What are the analytic advantages?

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

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.