Btw: An alternative to using changing IVs is to use a fixed IV, but encrypting and including 16 bytes of strong random at the beginning of each datagram.
This will make sure that a re-used payload, key, and IV, still leads to a strongly different ciphertext. This allows you to use CFB mode for each packet, without any inter-packet depdendencies.

Probably yes, but: (a) you will be transferring these additional 16 bytes per packet, and (b) I am not sure that crypto-guys will like it (technically, without inter-packet dependency, it won't be a CFB anymore, but a highly-insecure ECB; while you do address the key problem of ECB, on the other hand all the modes are very fragile, so any deviation is generally frowned upon in the crypto-community :-( ). In other words: I do not see big problems with your approach, but proving it would be a very different story :-(.

Btw: When using CTR mode for UDP datagrams, don't you have to bump the serial number by the number of 16-byte blocks for each packet you send?

Yep. In practice, you can reserve like 12 lower bits for block size (for UDP, going above 2^12*2^4=65536 is not possible anyway), leaving you with 2^116~=10^35 packets (and at a rate of 1000 packets/second it will last 10^24 or so years - well, I can sleep reasonably well with such a limitation ;-)).

If I use a DTLS lib I don't have to worry about encryption at all?

Yes, and you can forget about sequence numbers too (DTLS will do it for you). What you DO need to remember about, however - is to make sure that you DO run your own CA (certificate authority - it is as easy as running a bunch of scripts on a dedicated laptop), you DO issue a server certificate (signed by your own CA) to each of your servers (and follow some kind of policy on replacing them), you DO embed a root cert of your CA into your game client (don't forget to obfuscate it! - otherwise it opens a door for self-MITM class of pseudo-attacks), and that you DO check server certificate on the client side against this stored-root-cert-of-your-own-CA. Other schemas (with a 3rd-party CA such as Verisign) are possible too, BUT they have drawbacks in gaming environment.

If I use a DTLS lib I don't have to worry about encryption at all?

If you use the library correctly, and manage keys and certificates correctly, then yes.

The easiest way to break any crypto is to set up a web page that says "Free Game Gold Here" and have people log in with their name and password for your game on their site, under the pretext that they will get access to some secret hack or whatnot.
Social Engineering: It's like real engineering, except easier!

The easiest way to break any crypto is to set up a web page that says "Free Game Gold Here" and have people log in with their name and password for your game on their site, under the pretext that they will get access to some secret hack or whatnot.

Unfortunately, you're absolutely right. OTOH, 2fa does solve this particular attack (TODO for myself: check what is currently available for phone-based 2fa).

Social Engineering: It's like real engineering, except easier!

IMHO, social engineering is not really engineering, and is not even science, it's an art. Anybody who read Mitnik's books, realises it ;-)

OTOH, 2fa does solve this particular attack

Unfortunately, many options for 2fa don't reliably solve this particular attack. For most of the popular options (say, gmail's 2fa), an attack site can fake the page that pops up to say "enter your 2fa code here", and use the code and password the user enters to establish their own connection to google's servers...

Particularly because federated login via google, facebook, etc. is so common these days, users are trained to enter their 2nd factor when the page looks like the federation source popup. The only real defense here is to equip client software (i.e. browsers) to identify similar pages vended without the correct vendor server certificate - but that's a hard problem.

For most of the popular options (say, gmail's 2fa), an attack site can fake the page that pops up to say "enter your 2fa code here", and use the code and password the user enters to establish their own connection to google's servers...

You're right; I was speaking about classical 2fa with "what you know" (password) and "what you have" (cellphone). Even these can be abused (if password is accessible over the phone), but they're still much better than nothing. Ideal case for a 2fa is RSA/VASCO token , but these are expensive, and I know only of a very few games using them (mostly stock exchanges).

I was speaking about classical 2fa with "what you know" (password) and "what you have" (cellphone).

As did swiftcoder. All you have to do is pop up a dialog saying "enter your code here" and you have 30 seconds to post that valid code back to the original server, and you have a valid session.
Note even SmartCards or UbiKeys are immune. (Although they are cool, and integrate well with Google app services for business.) Tell the user to "press your key token now" and they will.
The trick is in fooling the user into trusting the site and giving up whatever credentials are needed. Hence, the "social" in "social engineering."

Tell the user to "press your key token now" and they will.

Yep, they will :-(.

All you have to do is pop up a dialog saying "enter your code here" and you have 30 seconds to post that valid code back to the original server, and you have a valid session.

AH, so you mean "live" attack rather than password-stealing. You do, though the impact of such an attack is (arguably) like orders of magnitude lower than with non-2fa password phishing. The difference between "you need to attack it live and it is over as soon as you're out" and "you've got the password once and forever" is a Really Big one in practice.

Yes, the surface area of sending email is a lot bigger than the surface area of a dedicated fishing site.
To the user that gives up their secrets, and then foolishly realized they've been "hacked," there's no difference though :-)
I guess my perspective is somewhat skewed by the fact that we're big enough and have enough revenue that there are many of each kind of such site and they all target our users, who then call to customer service to get help with their "hacked" account.
Google "free IMVU credit generator" or "IMVU product hacking tools" for a clear view of how a few bad people make the internet a terrible place.

Yes, the surface area of sending email is a lot bigger than the surface area of a dedicated fishing site.

From what I've seen some years ago, the most popular password-stealing attack was keylogger, and token-based 2fa (such as "RSA token") protects from standard keyloggers pretty well. To deal with phishing, it would be possible to have a little bit different 2fa with a USB token (the one which doesn't reveal credentials before authenticating the other side of TLS via standard PKI with a hardcoded root cert), but I didn't hear of the games implementing this kind of things (so far?).