I didn't say anything about implementing the MAC yourself. Someone has to implement it, though -- and no matter who writes the code, HMAC-SHA256 is far more likely to be right and not leaking data via side channels than CBC-MAC is.
Bespoke CBC-MAC is an almost-certain disaster. HMAC-SHA256 has some obvious implementation failure modes. It's less easy to see how someone screws up typing "CCM" into their library.
The point is that there are already shrink-wrapped AE constructions (like CCM or EAX) that you can pick up off the shelf and use; HMAC designs are more likely to be bespoke.
It's less easy to see how someone screws up typing "CCM" into their library.
If you trust the library, sure. But I've found that the same rules apply to crypto libraries as to everything else: Obscure and complicated features are far more likely to be buggy.
No crypto library is ever going to ship with a broken HMAC-SHA256 -- but I can't say the same thing about AES-CCM.
Seriously, Colin? You're talking about people that don't know to use AES-256 instead of Blowfish, but do know enough to homebrew instead of using a library?
CCM and EAX aren't obscure. AE crypto has been in 3 of the last 4 designs I've had to review. The fourth prompted a recent blog post of mine.
I didn't say anything about implementing the MAC yourself. Someone has to implement it, though -- and no matter who writes the code, HMAC-SHA256 is far more likely to be right and not leaking data via side channels than CBC-MAC is.