From the original BEAST paper, it seems to me that you need the same session key when encrypting data, so you can check if the original plaintext block is the same as your chosen plaintext (which is impossible with different keys). However, in modes with PFS, the keys are different in each session, so doesn't this foil the BEAST attack as well?
I appear to be wrong somewhere, but I can't see where. Can someone enlighten me?
BEAST is not affected at all if the keys are derived with Perfect Forward Secrecy. If you were to derive fresh keys quite frequently (that is, issue a Change Cipher Suite every couple of TCP segments), that would frustrate BEAST, however it wouldn't matter if the new ciphersuite used PFS or not. In addition, there are cheaper ways to foil BEAST.
What PFS means for SSL is that, after we are done with the session keys, no one can rederive what they were, even if they have access to all the long term keys (e.g. the RSA private key, if that were involved). The normal SSL ciphersuites do not provide this, as someone who has the recorded the negotiation and has the RSA private key can decrypt the premaster secret, and from there rederive all the keys.
However, with PFS, once we've derived the session keys, they are handled just like session keys from nonPFS ciphersuites; the keys are used to encrypt/decrypt traffic, and they aren't changed between TLS records (unless, of course, another Change Cipher Suite record is issued).
Hence, while this "no one can recover the session keys" property may be useful, it has nothing to do with BEAST. BEAST does not attempt to rederive keys at all. Instead, it tries to use the CBC-mode encryption as an Oracle (and then by injecting plaintexts that the attacker picks, confirms guesses on what earlier plaintext might have been). It does care that the keys used to encrypt this latter data was the same as the keys used to encrypt the earlier plaintext; however it doesn't care how the joint keys were created.
