Re: [TLS] PRF in 1.3

Michael StJohns <> Wed, 06 August 2014 20:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E40181A0198 for <>; Wed, 6 Aug 2014 13:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 00X0zu55spy0 for <>; Wed, 6 Aug 2014 13:10:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FE501A005C for <>; Wed, 6 Aug 2014 13:10:44 -0700 (PDT)
Received: by with SMTP id e89so3368831qgf.3 for <>; Wed, 06 Aug 2014 13:10:44 -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=b18KzhxJM7QJTUC7MsKqT94Yye8Ap1/lgumpHjmz9aU=; b=X5AnWAhEERiUpuGMfDrRBXQNZcGAEIxjKjUSUDMYrPR/RhscVOuF43xtYHLTUGo1Wx YoNF4fgEsuOxVelpHDMUT1ElNTqsTd/3VQnUfuDBTYGPYw+dQa4s4n3UzbEQj2n9gbZL FvIOc26nWrbmKgWt/qsClxf0aNpVe/26DweHG3/4SIgx40qYZdBS7UynFeZgvikyyvVu 03cKtrGG0r50glrkGr/mzIop1SJevtPb8aXB0S3E1ywaKvakghe3HeGb3GQ3Am85P33f JTGfI0RVNH1tUvfnBoIznxnd7UbRbAoUHIb58qd7LFqQK64CRqxAT74uKrwo9MHIeK9z hL2g==
X-Gm-Message-State: ALoCoQkJuDqz36WDJ64AB8KdWnLVNbmNx+YVh6MH+4lXKR0fiq7lQC2XUk6uwxnzz0RRF1nE2IxM
X-Received: by with SMTP id x6mr664795qax.1.1407355844112; Wed, 06 Aug 2014 13:10:44 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t23sm2055632qge.13.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 13:10:43 -0700 (PDT)
Message-ID: <>
Date: Wed, 06 Aug 2014 16:10:46 -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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; 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 20:10:48 -0000

On 8/6/2014 3:11 PM, Martin Rex wrote:
> Michael StJohns wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> 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
>> before.
> The PRF output is not used for in a signature style fashion.
> The default signature algorithm (for combination with RSA) in
> TLSv1.2 is either (sha1,rsa) or (md5,rsa), and particularly the
> latter is ludicrously weak in comparison to the tlsv1.[01] (sha1+md5,rsa).
> The problem with the Finished message in TLSv1.2 is that it still
> truncates the PRF output to 12 bytes (96 bits).  The HMAC rfc explictly
> says that one should not truncate to less than half the output size
> of the underlying hash function, so TLSv1.2 **should** have used
> Finished messages of at least 128 bits (16 octets) for a SHA256-based PRF,
> and at least 192 bits (24 octets) for a SHA384-based PRF.
> This is one of the TLSv1.2 goofs that should be fixed in TLSv1.3, btw.

I think you're still missing the point - the PRF *is* used as a 
signature function over a hash.  If the PRF were used as an HMAC 
signature function over the raw handshake data, it would be as secure as 
the HMAC (which is 256 bits for SHA256) underlying the PRF, but since 
you're signing the hash of the handshake data, you've no more security 
than the collision resistance of the hash which is 128 bites for SHA256.

The security of HMAC_SHA256 (key, SHA256 (data)) or PRF_SHA256(key, 
SHA256(data))  or ECDSA_521 (key, SHA256(data)) is no more secure than 
128 bits because the security of SHA256(data) is no more secure than 128 
bits for a signature function.

See table 3 of

I may be confused about this, but I don't think I am.

I think you're probably also right about the truncation issue for the 
finished message - but that's at least a little unclear because of the 
recursive nature of the PRF function.


> -Martin