The first (A) is that TextSecure truncates SHA-2 hashes and, particularly, HMAC-SHA2 MACs. MAC truncation is extraordinarily common and is a design goal for most authenticated encryption schemes. So far as anyone knows, truncation of SHA-2 hashes and HMAC-SHA2 MACs is completely safe; that is, HMAC-SHA2 isn't somehow less safe when truncated than GCM or Poly1305.
The second (B) is that the authors believed TextSecure to have swapped some of the parameters for the HMAC algorithm. Moxie has asserted that this is a mistake by the paper authors, and that TextSecure uses HMAC conventionally.
The third (C, and most of the rest of the paper) is an identity misbinding attack. An identity misbinding attack happens when it becomes possible for Mallory to present Alice's public key to Bob instead of her own, and have Bob reply with a message encrypted to Mallory-seeming-Alice. Mallory can't decrypt the message, but because it's encrypted to a key Alice has, Alice might act based on the message contents. Identity misbinding problems are endemic to public-key cryptography. They are a real issue for protocols in which computers chat with each other and take action (like, authorizing an HTTP request) based on identities. They are less of an issue in chat protocols. Of particular importance, contextually: every other chat protocol has much, much worse key management problems.
Brian Smith says that this paper has value as part of a formal conversation about the security properties of TextSecure. I'm not qualified to evaluate that statement. I don't see anyone saying the paper has practical import for TextSecure or its users. TextSecure remains the best thing out there, I think.
(C) is the observation that you could lie and claim someone else's fingerprint (print it on your business card, for example). This doesn't accomplish much, but is a general issue with fingerprints (e.g. OTR, SSH).
You can try to bind more of the context (e.g. hash more identifying information into the session key or MAC), but this makes things rigid, particularly if parties might be contacted under aliases (e.g., imagine if SSH servers needed to be configured with all possible DNS names they might be contacted under, and rejected others).
But even then, you can't 100% prevent this - if the protocol "binds" the phone number, you can lie and claim someone else's phone number, or name, etc.
You don't need to rely on the assertions of the authors; you can find the source at https://github.com/whispersystems/textsecure .
Or am I missing something?
I believe miniLock uses it, too.
Kudos to moxie and team for building usable free software; it's so much harder to build something that people can use than it is to criticize others' work.
There are many data plans in Europe where SMS are charged at rip off rates, and are something to be avoided. Even just the risk of sending SMS is enough to put anyone off using the application. Especially when competing solutions work as expected - i.e. they will not send SMS at all, ever.
TextSecure certainly seems the best option, but its adoption wouldn't help me a lot (I could migrate my wife, my parents - but I most certainly won't be able to use it beyond that circle) and - I really, really dislike central services for communication. This isn't even a serious trust issue, I do believe that the developers of TextSecure are genuinely offering a great and secure text chat experience (ignoring that other solutions promise the same - Threema et al for example, but TextSecure comes with a lot more credibility and therefor trust). But I like to stay in control of my infrastructure. The xmpp server is the best fit - but the protocol and clients cause some issues and No One™ is using it, so the federation is a moot point.
Unless something drastic changed (or I'm utterly misinformed) you could run your own server - and you'd split the network. The explanation was, as far as I recall, that there's no easy way to route things if all you got is a mobile number as an identifier (So .. on what server is that client? A JID has a host, a mobile number doesn't).
To reiterate: You probably could run your own server. In which case you and the 3-5 people you might convince to use that server would share some infrastructure under your control. You would not be able to send a message to the 6th friend that happens to use TextSecure, but _also_ needs to be on the authentic/real network to chat with his family.
Edit: Partially based on https://twitter.com/moxie/status/438049169052155905
What if TextSecure and RedPhone were installed by default on a mobile operating system?