RE: [TLS] Straw poll about default PRF

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

I vote for Option 1.

Stefan Santesson
Senior Program Manager
Windows Security, Standards
> -----Original Message-----
> From: Pasi Eronen [mailto:pasi.eronen@xxxxxxxxx]
> Sent: den 19 oktober 2006 06:09
> To: tls mailing list
> Subject: [TLS] Straw poll about default PRF
> 
> 
> Let's try to close the default PRF issue before the San Diego
> meeting.
> 
> To summarize the issue: to meet its chartered goal of removing
> dependencies 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.
> 
> Clearly neither alternative is horribly broken or unworkable, so this
> is mainly a question of "which seems nicer". Some arguments that
> have been made are as follows:
> 
> - Option 1 is not necessary, since there are no practical attacks
>   against the current PRF (yet)
> - Option 1 can cause implementation and/or interop problems
> - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause
>   big implementation and/or interop problems (there are interop
>   problems, but not because of the PRF).
> - With option 1, all ciphersuites benefit without having to get
>   new numbers (and there are lots of RFCs that would have to
>   be updated).
> - In order to have secure negotiation, all the PRFs that both
>   sides support have to be secure against a specific kind of
>   active attack (true, but would this suggest option 1 or 2,
>   or neither?).
> - TLS versions older than 1.2 have to be enabled for long time
>   (true, but would this suggest option 1 or 2, or neither?).
> 
> Please state your opinion on the WG list within a week. When
> judging the WG consensus, I will also take into account the
> sense of the room at Montreal, where support for option 1 was
> practically unanimous.
> 
> Best regards,
> Pasi
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls