[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [TLS] Straw poll about default PRF
Option 1 sounds good.
Larry Hofer
-----Original Message-----
From: Stefan Santesson [mailto:stefans@xxxxxxxxxxxxx]
Sent: Thursday, October 19, 2006 6:22 PM
To: Pasi Eronen; tls mailing list
Subject: RE: [TLS] Straw poll about default PRF
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
SPECIAL NOTICE
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.
Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies. To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls