[tomfitz]

Use TOTP as a fallback.

You might argue "well why bother with U2F, if you are going to set up TOTP anyway", to which I respond that using U2F is still a net win, because for the times you use U2F, you are safe from phishing attacks.

That in an emergency situation you have to use TOTP, and thus be vigilant that you aren't being phished, does not negate the benefits from having used U2F previously.

I can see that by enabling TOTP as a second-factor, it increases your attack surface. That is, you now have to care about whether your TOTP secret has been leaked. I consider this cost to be small, compared to the benefit of being able to fallback to TOTP. Others may decide this tradeoff isn't worth it.

[jimktrains2]

It's still not clear to me how u2f prevents phishing. If I was being proxied through a site with a valid tls cert, they still gain my password and a session key.

[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.