That recommendation wasn't about avoiding 'easy to screw up'. That one was about avoiding 'almost impossible to avoid having your key stolen via a side channel attack'.

Obviously, the comments about SSL are crazy.

Do you disagree with either of the following two pieces of advice?

  DO: Use SSL to secure your website, email, and
  other public standard Internet-facing servers.
  DO: Think very carefully about which certificate
  authorities you want to trust.

And, of course, I disagree with your reasoning about authenticated encryption. You're saying, "you're exposing your block cipher to direct attack by overloading it to both encryption and authentication". But it's probably exposed to side-channel attacks either way. Meanwhile, the implementation flaws that people end up with in naive HMAC systems break far more systems.

I suspect this is another example of the impedance mismatch between your academic approach to this and my "having to slog through people's terrible crypto on a monthly basis" approach.

Funny, my experience has been exactly the opposite.

But [your block cipher] probably exposed to side-channel attacks either way.

Exposed, yes. Exposed to attackers who don't hold the MAC key, no. Exposed to chosen-ciphertext side channel attacks, no. These distinctions matter.

having to slog through people's terrible crypto on a monthly basis

I do this too. But I try to educate people so that they write slightly less crypto.

The other thing that makes it ugly are the huge numbers of cipher suites and reliance on certificates (and thus usually centralized CAs.) The cipher suite growth came about because of export controls and then Internet-standards groups not seeing a problem with adding vanity modes. The reliance on CAs can be worked around with using your own cert store or using TLS-SRP for authentication, which is sorely underused.