Re: [TLS] New Key derivations for TLS1.3

Michael StJohns <> Wed, 25 September 2013 03:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF35D21F9339 for <>; Tue, 24 Sep 2013 20:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pm5zmREYOpdJ for <>; Tue, 24 Sep 2013 20:36:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D7DA21F9323 for <>; Tue, 24 Sep 2013 20:36:11 -0700 (PDT)
Received: by with SMTP id nd7so3768910qeb.21 for <>; Tue, 24 Sep 2013 20:36:10 -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 :content-transfer-encoding; bh=Gi0kx4NLnBTDcFiHt97LStjSHXt/fiBwplV28eZe3p4=; b=C1m+6bN5OBbYcgA93CgvPWgaC/2t9yFcDJj5RvzS3WRD6NXtLsU648BXNiIc7oBMbK NyTt6CDhAChJN23qXk7XOfanNNZLTJ90RQ/bjBDdB3qQojq/KJVlyK87vBAxCYDLpPt9 XdFpSzQXCLhx99+9W5O9fZz2f4Un5rFL/GQflEpPI768tnP4hxDC/yobkOcMmhL7rgqF ugB7KG2ozP1w4JPslHwIkm4z5b/pd9fDg1ciFZTO2v3hV54OADIsNBBVNawz5QFKLsVF n3XbDUbVOb5aRZysv7RTj2plwxPDZDHa598In281VnW7l8bNveWCKnzJYhS0RsUOC0Vi 5//A==
X-Gm-Message-State: ALoCoQn2ZU4AKAwvyX9vsc02wL/99Jn2FAzs+vcfpP92C10KhrZar91kHk2tiW4MjEVCiXL11Doa
X-Received: by with SMTP id f10mr41867342qcs.16.1380080170806; Tue, 24 Sep 2013 20:36:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u4sm61448928qat.5.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 20:36:10 -0700 (PDT)
Message-ID: <>
Date: Tue, 24 Sep 2013 23:36:10 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wan-Teh Chang <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] New Key derivations for TLS1.3
X-Mailman-Version: 2.1.12
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: Wed, 25 Sep 2013 03:36:18 -0000

On 9/24/2013 9:49 PM, Wan-Teh Chang wrote:
>> >By doing this, varying the length of any one of the sub keys completely
>> >changes the key stream.  That prevents the type of attack described by
>> >Juraj.
> I like this proposal!
>> >I spec'd 6 fields for the key expansion derivation instead of three to make
>> >this completely general - and to allow it to be used with the key material
>> >export RFCs.
> Could you elaborate on how your proposed change affects the TLS keying
> material exporter RFCs?
> Thanks,
> Wan-Teh Chang

Simply by adding the length fields to the KDF inputs used with the key 
material exporters.  So if an exporter needs 4 keys, there are 4 length 
values, 2 keys, 2 length values etc.   That makes what gets passed into 
the KDF the secret, the public values including the label,  and the 
length of each key and that construct can be used for the pre-master to 
master, master to key expansion and for any key exporters.  This is just 
an off-the-cuff suggestion at this point.

One other alternative is to only provide lengths for keys - anything 
after the end of the keys is public data.   That allows the 
private/public division  of data consistent with the current model 
without having to build a special function just for the key-expansion 
step.  And -  if you run this without providing any key lengths, you end 
up with the same key stream as the old function -and that simplifies the 
PKCS11 implementation.