Because of POODLE, and BEAST before it, CBC mode cipher suites shouldn't be accepted for TLS False Start. This is what is recommended in the new False Start I-D at https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-01#section-6.1: Also, various ciphers specified for use with TLS are known to have cryptographic weaknesses regardless of key length (none of the ciphers specified in [RFC4492] and [RFC5246] can be recommended for use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 ciphers specified in [RFC5288] and [RFC5289] can be considered sufficiently strong for most uses. Note that the reference to [RFC4492] and [RFC5246] is specifically excluding all RC4 and CBC-mode cipher suites. One good consequence of this change, besides the improved security, is that it may help us make progress on bug 940787.

Comment on attachment 8534484 [details] [diff] [review] false-start-gcm.patch Review of attachment 8534484 [details] [diff] [review]: ----------------------------------------------------------------- ::: security/manager/ssl/src/nsNSSCallbacks.cpp @@ +979,5 @@ > } > > + // Prevent downgrade attacks on the symmetric cipher. We do not allow CBC > + // mode due to BEAST, POODLE, and other attacks on the MAC-then-Encrypt > + // design. Maybe also include a reference to either this bug or the RFCs referenced in comment 0?

https://hg.mozilla.org/integration/mozilla-inbound/rev/b20889a1ccc0 I included a reference to this bug in the comment, as you suggested. Thanks for the quick review!

Comment on attachment 8534484 [details] [diff] [review] false-start-gcm.patch Approval Request Comment: See bug 1084025 comment 52. This is part of that issue. The only difference is that *this* bug's patch is very low risk because it only affects whether we do a performance optimization or not. The only risk is the potential for a performance regression in some cases. Note that Google Chrome is planning to make the same change, with the same security-vs-performance tradeoff; see the Chromium bug link above. My intent is to uplift this to -aurora along with bug 1084025, and then to -beta later.

Should this be part of the release notes?

As per comment 5, do you think this change should be relnoted in 36?

Yes, the changes to the false start behavior should be documented in the "what's new/changed for Developers" documentation.

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #8) > Yes, the changes to the false start behavior should be documented in the > "what's new/changed for Developers" documentation. Thanks for confirming. Can you suggest the wording for the note?

"Firefox will only attempt the TLS False Start optimization if the server chooses a cipher suite that uses the AEAD construction--either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Both of these cipher suites require TLS 1.2."

Actually, s/Both of these/These/.

Can I shorten that note as "TLS False Start optimization now requires a cipher suite using AEAD construction" Do you have a link to documentation about this that I can reference for the additional details?

Sure. And, I don't have a link to a document.

Thanks. Release note added to desktop and mobile.