Subject: AI : follow up to Issue 14
On the question of using P_SHA1 rather than the full PRF function defined in TLS:
The assumption of PRF is that either SHA1 or MD5 would provide sufficient security so PRF has two independent terms using each of these. History has shown that SHA1 is more secure than MD5, so if we believe that PRF is secure, then we correspondingly believe that SHA1 is secure. For simplification reasons, the derived key specification chose to simply use the P_SHA1 given that MD5 wouldn’t provide additional security. In terms of analysis, I believe the original TLS work provides sufficient material here since P_xxxx is defined as a general algorithm for any digest and the combination of SHA1 and MD5 was historical.
On the question of recent SHA1 attacks:
Many crypto folks still feel that P_SHA1 is a reasonable choice given how we are using it for derived keys. However, since TLS does define P_xxxx as general function for digest algorithms, we could define an alternate derivation key algorithm that uses P_SHA256 (either truncated or not). We could explore that as an option, but I don’t see any reason to drop P_SHA1 since many folks believe it still safe and many have this code implemented and interop tested already (e.g. as part of TLS stacks).