The MITM-related issue with SQRL derives from the fact that the authentication request and response happen across two different channels, and an attacker can successfully conduct a valid authentication request/response from an invalid site. That is, an attack site could fetch an SQRL code from the correct site, and present it to the victim. The victim can authenticate against the provided request, but by doing so he'll log in the attacker instead. The lack of coordination between the browser and the phone means that you can't protect this step.
In this sense, SQRL isn't any more susceptible to phishing/MITM than passwords, and it's somewhat better in the sense that authentication has to happen online. But it's worse than existing alternatives, and that's the problem.
So, for example if your mother or boss or coworker or friend says to you: "I want to be more secure online, should I use SQRL?" Your answer must be: "No, use Lastpass and random passwords instead."
The fundamental difference here is that browser integration thwarts all phishing attacks, and since phishing is by far the most serious threat to your online safety, this should be your first priority, trumping all else. No alternative should be even considered if it doesn't protect against this threat, because it's the one you're most likely to face. If you're going to switch, switch to something that will keep you safe, not something that won't.
What of GRC's Countermasures?
GRC's first point about how SQRL codes are unique to a given site is irrelevant, and I'm not sure why he bothers to mention it. Basically he's saying that paypal.evil can't generate their own SQRL code for paypal.com. The attacker would have to fetch an authentic code from paypal.com and present it to the user. Which is exactly what they'd do.
The "Login Redirection" countermeasure is really only feasible if you're using browser integration... in which case it's completely unnecessary, since the browser can already tell whether it's at the correct site or not. If you're using SQRL with a phone as originally designed, then the "login redirection" link would have to be manually typed into the URL by someone reading it off the phone. So... that's not going to happen.
The "Action confirmation" countermeasure is a load of silliness. The idea is that you log in to the bank with SQRL, then each and every activity (including viewing sensitive data) done on the bank website would have to be manually confirmed on the cell phone. It'd be like using the bank's own cell phone app, but with added inconvenience.
The source-ip verification stuff that GRC goes into great detail about is a hack. The protection is inconsistent and incomplete, and implementation would be messy and error-prone to say the least. This is important because while it may be "better than nothing", it's not "better than the alternative"; you can actually have good security, but this isn't it.
All of this is an attempt to retrofit critical safety provisions into a system where it wasn't designed to fit. And that's really the core of the problem: the system was built to solve uncommon or nonexistent problems, while ignoring real, serious, and pressing problems. So we're taking a system that was poorly-designed to begin with and attempting to patch it to make it "professional-grade". That's kind of like taking skyscraper blueprints drawn by an auto mechanic and attempting to fix them to make something that could actually be built. The most practical and effective approach is to start over from scratch.
Could we build a secure alternative?
Of course we could. But the key to doing so is to look first at your primary usage case and threat model, and build the system accordingly. For example, SQRL was designed such that all authentication happens on your cell phone. You could retrofit the solution to allow for browser integration, but all the features and design decisions were based around the assumption that your cell phone is your identity, which is why phishing protection is so difficult.
Designing a system to address all of the most likely attack scenarios really is simple. All the necessary components exist, and all the problems have already been solved. I won't go in to the details here since this isn't the place for it, but I would wager that if you asked a dozen real security and identity experts, they'd all come up with roughly the same design.
