Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

Michael StJohns <> Mon, 27 April 2015 00:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0FC461ACEED for <>; Sun, 26 Apr 2015 17:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k5K2Pj1BRF1E for <>; Sun, 26 Apr 2015 17:01:50 -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 B2A911ACEFB for <>; Sun, 26 Apr 2015 17:01:50 -0700 (PDT)
Received: by vnbf190 with SMTP id f190so10033498vnb.1 for <>; Sun, 26 Apr 2015 17:01:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=+OQtW2mClIf2p5CXmETXXLRr6jC9TukacvFH90KxHwM=; b=CzMxwuO8nro7a8fKJj2EMwLjgvBhTcuSLUkVjkoYb6zVUh8WryVH3uTaHEyvH0onaa 2wlMpXNFGfPqAiYoVcy/D9jCIjLwjU1enn4urW027RT4jkdrG6tBDZaYd+O0BxmOfpe9 T4fqPFsNZG+D70SKdAk3LApTFKlJ9ZxLP4X7WeTnnztaOVAVShVgT1xzOMq2lwqdUiEg SU/wTTP1Gcf41QY3UzsECJoTduhXc0kMlZk16XqPYE5bGveBGoCHVUTCim+FnOki9ems I6qIUj9VTmjuaqEYatyB+EOkVRcdMI9rZONvJYx+k3BkZPR2Dt6Z00W8YcSRDGmBBtrO h6XA==
X-Gm-Message-State: ALoCoQnmtztBk7/WdrkaW8kMLzfu8xGWGFGV/0HPr8GXJA9/z2tZ+k/kxY5F06QrvyQDZjs15NfJ
X-Received: by with SMTP id vw14mr21599836vdc.29.1430092910012; Sun, 26 Apr 2015 17:01:50 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by with ESMTPSA id mk16sm21456013vdb.12.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:01:49 -0700 (PDT)
Message-ID: <>
Date: Sun, 26 Apr 2015 20:01:48 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Hugo Krawczyk <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050901030100020508060000"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
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, 27 Apr 2015 00:01:52 -0000

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>     You can include the length term in info, but it won't be enforced
>     by the HSM and depending on the format of the INFO field could
>     actually be spoofed as this is all user supplied info that isn't
>     known to be related to the actual desired output length.
>  Adding the length is not a solution to spoofing attacks- it will not 
> differentiate between keys of the same length.
> You cannot compensate via the KDF for unauthorized access to the HSM. 
> If the HSM doesn't enforce an access policy, it is the HSM problem, 
> not something to solve via the KDF or via TLS 1.3 spec.
> ​

Adding the length is not a solution to spoofing attacks and does not 
differentiate between keys of the same length, but it will differentiate 
between keys of _different_ lengths which is where the attack comes 
in.   The problem is not in the math of the KDF, but in the HSMs ability 
to determine how to convert key stream material into concrete keys in a 
manner that doesn't subject them to attack.

If I have a key that's derived from another key, I would like that it 
not be trivial for an attacker who has access to the HSM to extract that 
derived key.  I believe that making the change to add the length makes 
it difficult to do such extraction and apparently(?) so did the 
reviewers of SP800-108(?).