[tomfitz]

U2F keys are linked to the associated domain (e.g. google.com or dropbox.com), so your U2F would not present your google.com key to a U2F prompt on googlehax.com

This stops the proxy attack you describe getting a session key, but not getting your password. Of course, the password alone is insufficient.

[jimktrains2]

To clarify, the U2F key never leaves the device; only a signature.

In what sense are the keys linked? I'm assuming it requires the browser to pass the actual domain requesting the auth?

[pfg]

The browser passes the origin (protocol + hostname + port) to the key. This field is included in the data the key signs. The signature would not match for an authentication response obtained via phishing because of that.

Your original description is a bit ambiguous: were you referring to a case where the actual domain was being successfully man-in-the-middle'd with a valid TLS certificate? That's not something U2F aims to solve (and not something that people generally refer to as phishing).

Edit: Small correction: U2F makes use of TLS ChannelIDs, which, if I understand correctly, would help in that scenario (MitM with a trusted-but-attacker-controlled certificate on the "real" origin). I'm not sure if anyone other than Google makes use of this yet, as it requires a new TLS extension on the server.

[jimktrains2]

No, you answered my question. I accepted that any/most/all authentication breaks down in some way of you can't trust tls certs or the browser/user agent.