Re: [TLS] Straw poll about default PRF

[Rob Dugal <RDugal@xxxxxxxxxxxx>]

I prefer option 1.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@xxxxxxxxxxxx
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

"Pasi Eronen" <pasi.eronen@xxxxxxxxx>
wrote on 10/19/2006 09:09:01 AM:

> 
> 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