# What's the reasoning behind the design of the TLS 1.2 PRF?

TLS 1.2 defines a PRF-like construction $P_{hash} : \{0,1\}^* \times \{0,1\}^* \rightarrow \{0,1\}^l$ for key derivation, etc. To quote the spec:

We define a data expansion function, P_hash(secret, data), that uses a single hash function to expand a secret and seed into an arbitrary quantity of output:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...


where + indicates concatenation.

A() is defined as:

A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))


Why does $P_{hash}$ invoke HMAC twice per block of output? Are there valid security arguments for doing so?

In particular, why not a simpler, faster, counter-based scheme such as:

$P_{hash}(\text{secret}, \text{seed}) = B(\text{secret},\text{seed},0) \| B(\text{secret},\text{seed},1) \| \dots \\ B(\text{secret},\text{seed},i) = \text{HMAC}_{hash}(\text{secret}, \text{to_byte}(i) \| \text{seed})$

If there is no technical advantage, what are the historical reasons behind this design?

• If TLS were designed today, we'd probably use HKDF instead. Apr 9 '16 at 8:04
• @CodesInChaos It is being designed today, and it uses HKDF. As you well know, I suspect :) Apr 9 '16 at 23:45
• @MaartenBodewes not so sure I'd call it being "designed" so much as monkey-patched. Some of the decisions for 1.3 aren't going near far enough. Still way too many options in there. IMHO there should be exactly two cipher suites, and everything else is either a MUST or is completely out of the spec. Or is there a TLS 2.0 WG coming up with something simpler that can actually be implemented securely and analyzed? Apr 11 '16 at 4:19
• @rmalayter A TLS that will be implemented securely? Dream on ;) Apr 11 '16 at 18:10
• @rmalayter You may be interested in my answer to the question here. I think you'll find that we kind-of agree on this. As for this question, it might be that the reasons are lost in the mist of time. Jun 18 '16 at 11:42