It does not, and we don't plan to push forward on that, at least at this time.
The thing is, although it is the focus of that article, it would not actually have prevented this attack (the MITM certificate was CT-logged and had a valid SCT extension). SCT checking only makes sense in combination with a CAA record and the assumption that no CA could be legally compelled to issue a CT-logged certificate regardless of the CAA record. As far as I'm aware there is currently no way for the CA to prove the CAA existed (or did not exist) at the time of issuance (I'd be happy for someone to correct me if this is wrong, it feels like a big gap in the model).
Channel binding provides far better security guarantees, and does not depend on any third party. That's our focus for the upcoming release.
They do, yes. It's certainly a requirement if channel binding is to work at all.
Additionally there is this proposal to also detect attempted downgrade of the channel binding and SASL mechanism lists themselves: https://xmpp.org/extensions/xep-0474.html - which we're currently looking for expert eyes on, if you know any... :)
The thing is, although it is the focus of that article, it would not actually have prevented this attack (the MITM certificate was CT-logged and had a valid SCT extension). SCT checking only makes sense in combination with a CAA record and the assumption that no CA could be legally compelled to issue a CT-logged certificate regardless of the CAA record. As far as I'm aware there is currently no way for the CA to prove the CAA existed (or did not exist) at the time of issuance (I'd be happy for someone to correct me if this is wrong, it feels like a big gap in the model).
Channel binding provides far better security guarantees, and does not depend on any third party. That's our focus for the upcoming release.
Edited to add this related discussion a few days ago: https://news.ycombinator.com/item?id=37958552