(TLS-OBC is not yet a RFC, just a proposal, and, as all drafts, can be subject to change.)
As presented, TLS-OBC is an extension to the SSL/TLS protocol. There is a scheme for such extensions, which can be added at the end of the
ServerHello messages. Nothing related to TLS-OBC happens unless the client and then the server agree to use them. Possibly, some very old and buggy servers could choke on the
ClientHello from the client, but the same can be said of every other extension and it does not prevent browsers from using, for instance, the Server Name Indication. So no real issue there.
Possible issues that I see with this draft include:
When TLS-OBC is used, the server should not send a list of accepted CA, and the client MUST ignore them anyway. This means that a given server accepts either OBC-type certificates, or standard certificates, but not both. Moreover, the server must make this decision before knowing the target path, so it is a server-wide setting.
The OBC is remarkably efficient at tracking clients -- that's its point, really, when it is used as a "strengthening of the cookie". This implies the same kind of privacy issues than cookies. I suppose that browsers implementing TLS-OBC will provide the same kind of choice than with cookies (i.e. a way to deny OBC usage with some specific servers).
Contrary to normal client certificates, OBC do not prevent institutional Man-in-the-Middle attacks (when a proxy servers creates a fake server certificate on-the-fly -- this assumes that an accomplice CA is installed in the client trust store, which is a relatively common setup in some big organization which want to monitor their employees closely). The "attacker" (possibly a legitimate attacker, as a sysadmin) just has to substitute his own OBC.
Mostly, I do not see clearly in what way OBC really increases security.