Re: [TLS] Straw poll about default PRF

["tom.petch" <cfinss@xxxxxxxxxxxxxx>]

Option 2

(Option 1 may be suitable for the present situation but may become a liability
at the next version change.  Option 2 gives us the better long term control).

Tom Petch

----- Original Message -----
From: "Pasi Eronen" <pasi.eronen@xxxxxxxxx>
To: "tls mailing list" <tls@xxxxxxxx>
Sent: Thursday, October 19, 2006 3:09 PM
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