I think this ends up in the same situation, but with the "bad actor" ISPs spoofing TLS instead, presenting self-signed certificates instead of the real ones (once they become accepted as "good enough for normal traffic"). I asked Lauren about this and he said, in part:
It makes an enormous difference from a legal standpoint, I believe. ...It's something else entirely [than tampering with unencrypted communications] for them to manipulate an encrypted connection and certificates in a manner that most observers would consider to be forgery.
It may be true in a sort of public-opinion sort of way but I think that if rewriting TCP packet contents isn't already forgery, then rewriting encrypted TCP packet contents isn't either. I may be on the wrong side of this, but conventional forgery law does not require that the protection against forgery be set to some arbitrary "toughness", does it? I would argue that source IPs, sequence numbers, and packet checksums are enough of a "signature" that it is hard for me to see a legal distinction being made. (Perhaps the difference is merely whether it is "effective" but the DMCA has shown us how fuzzy that line can be--- what's effective today may be utterly ineffective tomorrow.)
I think it is useful to step back and try to decide what we want to accomplish here. <academic mode="blowhard"> There is no technology which can ensure that a particular ISP will actually carry your traffic, or prevent the ISP from modifying it. The best you can hope for is to discover that the ISP has not delivered your packets (though this is hard), or has altered them in transit.
Suppose you do discover that your ISP is a bad actor. The proper response is to switch ISPs, not continue using them and hope that they behave better in the future, or that you can win some sort of technological/legal arms race. (Your ISP can ultimately "win" by cutting off traffic that they can't modify.) Alternately, you can sue them without introducing new technology if you believe their actions violate the law or your contract with them.
So, a proper response might be to say: What legal and regulatory framework needs to be in place to enable a meaningful choice in ISPs? What social and technological mechanisms are required to detect and publicize that an ISP is a bad actor? As an answer to the latter question, TLS seems both unnecessary in many cases (the change inserted into Google's front page is not subtle) and ineffective in others (man-in-the-middle attacks using self-signed certificates.)
<academic mode="wild and crazy">My advisor, David Cheriton, made some suggestions a few years back about a different way to look at problems like this. The core idea is that you can build some degree of trust by looking at whether information is the same when it comes via different channels. If you are connected to the Internet via two ISPs, it is practical to ask for a certificate via both of them and see whether it matches. If you can communicate securely with a set of peers, you can compare the answers you get with those your peers received. This suggests different ways of building trust that may be more scalable.
A "real-time" version of this approach is outlined in a paper we wrote entitled Feedback Based Routing which suggests that a good way to secure wide-area communications is to develop multiple paths to a destination, and use end-to-end feedback to determine which should be used. Perhaps, if one is worried about TCP rewriting by your upstream ISP, the best technical solution is to split TCP sessions across two or more upstream ISPs, thereby denying any single one the ability to transparently modify your connection.