Authentication of the parties at each end is one issue, but only one of them. What I mean is that most protocols should be encrypted by default, rather than by exception. Let us take the web for example.
- When you make a request, your browser first telegraphs its intentions by doing a DNS lookup of the desired host.
- Once an IP address is determined, your browser makes a request, usually in plaintext.
- The typical, non-SSL connection trusts the domain registrars and DNS hosts that the identified address matches the actual site.
- The user provides plaintext (usually) credentials, on the iffy chance that the site even requires any.
- The response is also unencrypted, so the entire process is totally in the clear as a general case.
Like the AC said, it's the Stasi's wet dream. You have gone and told your ISP, the web host, and every snoopy-assed dog in between exactly what your on-line identity is, who you're talking to, what was said by each, and probably the credentials you used to log in.
Without getting into the hassles of key management for crypto, let us compare this to a simple (-ish) SSL session:
- You have still leaked your DNS request. In the typical case, your ISP knows what hostname you're looking for in your browser request.
- Your browser makes at least some attempt at verifying the identity of the web site. Yes, SSL has issues with knowing who to trust, but the alternative sucks donkey balls in comparison. Your common-use, current browsers will squawk for most dodgy attempts, and getting around this requires more subterfuge than the average bear.
- Your communications with the end host are encrypted. What ever you asked for, and receive, as well as any login credentials, are hidden from prying third parties. Your ISP knows little but the hostname, unless you have installed browser certs which let them perform a MITM attack.
Not perfect, but better, yes? Now multiply this across other common protocols. Email (both ways), chat, file transfers. It's a great start.