Nobody has ever presented any evidence ever that NSA has Google's SSL/TLS keys. Not only that, but Google has (a) pinned their public keys so that the browser binary itself can reject bogus- but- signed certificates, and (b) pushed heavily to enable forward secrecy in TLS, which means that even if you compromise their key, you can't decrypt sessions without being an active man in the middle.
That's one, but the basic mechanism --- deriving session keys from RSA-signed DH exchanges --- is old, and is simply a ciphersuite (Google deploys an ECC-version of it for performance).
That proposal is for an ephemeral, per gTLD client key and an example of mutual authentication that aims to defeat _active_ attackers (MITM).
Perfect forward secrecy in TLS is a bit different in that the ephemeral diffie-hellman key exchange sets up a shared key that is protected from a _passive_ attacker that observes the TLS encrypted communication and later gets a copy of the server's public key.
Not quite. Having someone's private SSL key doesn't necessarily let you read the contents of their SSL traffic due to forward secrecy. It does let you sign messages as if you were them, or MITM their traffic.
For instance, on HN, Chrome is currently doing this:
Your connection to news.ycombinator.com is encrypted with 128-bit encryption.
The connection uses TLS 1.2.
The connection is encrypted using AES_128_CBC, with SHA256 for message
authentication and ECDHE_RSA as the key exchange mechanism.
Using ECDHE_RSA, my browser and HN's server will agree upon a key to use for encryption using AES128 in CBC mode. Now in order to read what the server sends me and what I send to the server, you need to break the crypto:
1. Brute force the 128 bit key. This is.. probably not going to happen?
2. Via a weakness in the AES128 algorithm or implementation, you can simplify a brute force into feasibility (AFAIK, no such attack currently exists).
3. Via a passive attack on ECDHE_RSA, you could potentially guess the shared key efficiently and decipher our communications (AFAIK, no such attack currently exists).
So it's not quite as simple as recording encrypted information and obtaining the SSL keys. You need the server to actively remember the keys used for every encrypted connection, and obtain those, too. Or MITM everything and record the unencrypted data.