Re: [TLS] PRF in 1.3

Michael StJohns <> Wed, 06 August 2014 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 656231B27D6 for <>; Wed, 6 Aug 2014 11:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XM_1Tm89x4tf for <>; Wed, 6 Aug 2014 11:57:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77C5D1B27CB for <>; Wed, 6 Aug 2014 11:57:56 -0700 (PDT)
Received: by with SMTP id j15so2992956qaq.29 for <>; Wed, 06 Aug 2014 11:57:55 -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=EFmXiWPwm0lseu7BQAIy/SJj0gJ2eMnYacH+BZU6jW8=; b=StY8CuDqtRjcd5t3pZgwaX7BitbROSiWvBurV51Cr+wRM+SrNjUvkAFEZ5TPCzsbrp pOOX4nuIgYxWLKuiMGsX2exFhZ69dDxOhtHtEOUwVbH3jJAsxAUpOfqTr+wOUzJWyjd1 zJZZdUyLbbDAUQYQ1WKrRKbd9Fwbex4mzFpuPsHF/F/83EazzZXLCaTcvb+5LdF0I4Rc SEpB0JU+IeLJ0XClT/a78hAeVQvel1+7OUavKti2ASyV8AHQhAEuK7TB1jRsHchxFHGx AKIwdbQTafFjQwe0z4XBMkhUgHJiODVMFRyzztNt9x5YY50nMjakpy5Rz7tS+z/Rbw1D az8g==
X-Gm-Message-State: ALoCoQk4vmg1lNdG8YGRhfB5DsJ+cgKFyJRppxAW+5UIzHhEo2IxzTGipCL/P5O8r/b7xCdDTYUB
X-Received: by with SMTP id p71mr5985587qga.86.1407351475531; Wed, 06 Aug 2014 11:57:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 38sm1856421qgp.30.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 11:57:55 -0700 (PDT)
Message-ID: <>
Date: Wed, 06 Aug 2014 14:57:58 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?SGVucmlrIEdydWJic3Ryw7Zt?= <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] PRF in 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: Wed, 06 Aug 2014 18:57:58 -0000

On 8/6/2014 7:43 AM, Henrik Grubbström wrote:
>> that - see
>> >, and I
>> >would add information about the types and lengths of the keys to be derived
>> >from the key stream to the context.  With those changes, a recursive based
>> >HMAC PRDG at the heart of the KDF is probably sufficiently secure for key
>> >derivation going forward.
> I'd like to hear from the people that rejected P_SHA256 for the AES256
> suites in RFC 5289 (which instead use P_SHA384). I suspect that it is
> to avoid leaking the entire state of the PRF in the AES256 keys and/or
> to avoid correlation between the client-side and server-side keys.

I think this is actually not a question with respect to the KDF use of 
the PRF, but with the "PRF(k, HASH(handshake messages))" formation of 
the verify_data in the Finished messages.

HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k, 
SHAXXX(data)) (which is really what the PRF is being used for here) is 
only XXX/2 bits of strength - or so I understand from the NIST key 
management special publication.    That would place the strength of a 
suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and