I don't think there's anything inherently bad about trusted MITM. If the trust exists, then you can have a local caching proxy that can drastically reduce the load on servers, WAN links, etc, and is a major part of Roy Fielding's original description of the REST architecture. [1]
IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way.
But uncle Joe and grandma Margaret don't care about confidentiality. If they did, they wouldn't crab about that shifty Snowden guy, and they would donate to the EFF. They just don't want their Facebook login stolen, or their banking login sold on some forum, or their family photo gallery erased. Confidentiality, for the unfortunate majority of Americans anyway, just isn't a selling point.
>They just don't want their Facebook login stolen, or their banking login sold on some forum, or their family photo gallery erased.
That is confidentiality, no? If login credentials are transmitted in the clear then anybody listening can impersonate them. That's exactly what FireSheep demonstrates.
IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way.
[1]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
[2]http://en.wikipedia.org/wiki/Message_authentication_code