WebAuthn is less phishing resistant than it should be. The original intent was that WebAuthn + token binding would ensure that, even if an attacker obtained a fraudulent certificate for a victim site and had an MITM position on the network, the attacker still couldn’t steal a WebAuthn protected session. Alas, Chrome removes its token binding implementation, and WebAuthn no longer has this property. If you authenticate with WebAuthn, and there is a MITM, the MITM gets your session.
(Conventional phishing is still prevented. If you go to, say, g00gle.com, the owner of g00gle.com can’t reuse your authentication to authenticate to google.com. But this relies on your browser actually knowing what domain it’s looking at, which relies on the CA system.)
The WebAuthn specification still explains how you could get token binding if it's present, it's just that it isn't present on any major implementations today.
I'm not sure I believe that real bad guys can successfully attack the Web PKI yet would be foiled by a site using token binding. I think crooks sophisticated enough to burn an exploit to get themselves a fraudulent certificate and put themselves on path for the main attack probably just break into the actual target web server and dispense with everything else entirely. I'd welcome token binding as an option, but I expect I'd never use it in my software.
If you include attackers who control an organizational MITM CA in your threat model, then this could be a big deal. If I were, say, a bank, I would like WebAuthn to protect me against compromise of an organization’s MITM box. Token binding can do this to some extent.
Surely in most MITM box scenarios the token binding just isn't possible?
The only correct MITM box design for TLS is back-to-back client and server, and with that structure there are two TLS channels instead of the one you expected so you can't bind anything to "the" channel between your client and the destination server as there are in fact two channels.
Hacks to try to do something else invariably break and make everything worse. The resulting wreckage for TLS 1.3 took a year of engineering plus an extra year of whining MITM box owners reluctant to stop doing broken crap. We certainly don't want to encourage more of that.
So you are vulnerable to an active MITM, but they don't actually acquire any private secrets to be used to create their own sessions. MITM with passwords OTOH, gives the attacker your password.
That depends on how the site works. On most sites, when I authenticate with WebAuthn (or by any other means), I get a bearer token good for several weeks. So a single spoofed WebAuthn session gets the attacker access
for quite a while.
AFAIK Microsoft added token binding back in the Edge version based on Chromium. As other commenters pointed out, token binding is still part of the WebAuthn spec.
(Conventional phishing is still prevented. If you go to, say, g00gle.com, the owner of g00gle.com can’t reuse your authentication to authenticate to google.com. But this relies on your browser actually knowing what domain it’s looking at, which relies on the CA system.)