The phishing emails that I receive and disect all have used MITM techniques to varying degrees. The most common is to use the real site for all but the password send. That one transaction is spoofed. I don't usually disect them further because it's not my job. I'm curious so I figure out how the initial spoof works.

Other experts inform me that you then find either more partial MITM, where the presented information is from the genuine site but the send action in the submit is to the attacker, or complete MITM where they forward on the password.

The extra step of complete MITM is growing in frequency, as are the even more difficult to stop piggy backing attacks. There is even one phish going around that directly attacks the SSL system by persuading people to "update" their system with bogus new trusted certificates for the specific bank being targeted. (See some of the SAN logs.)

As for the other side issues:
1) The genuine DNS attack that I experienced was done by attacking the registrar, and would not have been stopped by authentication. (It was the panix attack.) I use panix and my ssh authentication method caught this one a few hours after the attack. It was a great surprise to me, since I had previously viewed my security fetish as an "eat your own dogfood" effort with no expectation that I would detect anything. Protecting the DNS system is a good idea, but it is insufficient.
2) On general authentication, too many people have drunk the cool aid. For all but a few instances, all that you need to know is that it is the same person as the previous times. You don't need (or even want) a major authentication system for this. Simple SSL with a white list suffices.

For example, typepad uses an https submit action. Everything else is http. I don't need to know who typepad really is. What I need to know is that this is the same people as it was all the previous times. This simple step, if taken by all the legitimate password users, would defeat all the simple MITM phishing.

Even when it comes to payment transactions, since I use one time credit card numbers, I have a very limited exposure so all that really matters is that the people who I gave the credit card number are the same people that I use for the services. I don't need to know much more. If there is a dispute, there might be added value to knowing more, but the dollar amount is small enough that it is not worth much money.

The liability limits on credit cards results in the credit card companies doing a good job of detecting the major frauds. This plus the use of one-time credit card numbers is a simple step that substantially shifts the attacker targets. (It probably increases the phishing attacks, since the goal now becomes obtaining enough information to fraudulently establish an account, rather than stealing the credit card number.)

The present "trust anyone who is trusted by ABA.ECOM" logic is actually much weaker. Who is this outfit? (It is the American Bankers Association, but that you learn only with some serious digging. I still haven't found where they have information to let me independently confirm that the certificate that I have is the one that they published.) I know who "Staat der Nederlanden" is but why should I be letting them make these decisions? In fact, I want to know that the https submit of the password to typepad actually went to typepad. The present setup is that the browser is happy as long as it goes to somebody that is trusted by a root authority. That is silly. It's much more important that it be the same people (perhaps using a self signed cert) than that it be someone trusted by America Online.

When dealing with large amounts of money or really critical transactions, I ask for an independent channel verification such as telephone or SMS. At present, the only way to crack that one is to crack the people that I am dealing with. I know of no attack that will successfully perform a coordinated penetration of both my computer and my cellphone.

PS another growing trend in phishing is tricking the target into installing a keystroke logger. That kind of end-point attack is not stopped by SSL. Only changes that do not use a keyboard for all the input work as defenses. The growing trend is to add "pick a picture" to the password cycle, to interfere with the keystroke loggers. These keystroke loggers are a better argument against investing too much effort in authentication activities.

You can defeat keystroke loggers and many other attacks if you start using mutual authentication instead of merely server authentication. This is a lot of work, but much higher eventual value.