Pasi Eronen wrote:
Let's try to close the default PRF issue before the San Diego meeting.To summarize the issue: to meet its chartered goal of removingdependencies to MD5 and SHA-1, TLS WG will most likely specify a PRF that is not based on MD5/SHA-1 (the exact details will be determined separately). TLS 1.2 will also most likely allow new ciphersuites to specify a ciphersuite-specific PRF (e.g. the GOST ciphersuites).The remaining question is exactly how the PRF negotiation will work for those ciphersuites that don't specify anything, especially all the currently defined ciphersuites.The two main alternatives seem to be as follows:1) Default PRF is tied to the TLS version number: in other words, ciphersuites that don't specify anything else (including all currently defined ciphersuites) will use the new TLS 1.2 PRF (details of which are TBD) when TLS 1.2 is negotiated.2) The new PRF will be used only for new ciphersuites that explicitly say so; all currently defined ciphersuites continue to use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.
I vote for option 1. Wan-Teh Chang
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls