Hi all,

I went ahead and removed the DNS method from XEP-0156 instead, and updated the security considerations and business rules to explain that TLS should always be used and what to send in SNI and what to look for in the certificates.

Please let me know if anyone has concerns with this.

Thanks much,
Travis

On 2/13/22 15:52, Sonny Piers wrote:
Thanks you Travis for taking the time to make individual reports for each implementations. I fixed it in xmpp.js 0.13.1 .

If that works for everybody - I'm happy to remove BOSH / and XEP-0156 from XMPP Compliance Suites 2022.

If someone disagree please come up with a different solution than obsoleting XEP-0156 all together . BOSH without an endpoint discovery mechanism doesn't make sense in a compliance suite.


On jeu., févr. 10 2022 at 19:48:47 -0700, Peter Saint-Andre <stpe...@stpeter.im> wrote:
Co-author of XEP-0156 here. Thanks for raising this issue. I would go even farther and note that DNS TXT records were never a great idea for this functionality (they're actively discouraged in the DNS community for application-level uses like this). On 2/9/22 4:29 PM, Travis Burtrum wrote:

    Hi all, The long story short (is outside of DNSSEC) it's
    impossible to use _xmppconnect TXT records to securely connect to
    BOSH or WebSockets. Every client I've been able to find that
    supported this is vulnerable to trivial MITM (Man-In-The-Middle)
    via DNS spoofing.  If you have a client that uses it, switch to
    grabbing host-meta via HTTPS per [RFC-7395] immediately, maybe
grab a CVE if you wish. Sonny commented on your PR that "RFC 7395 doesn't define bosh lookups"; this might be true but that raises the issue of whether we should still recommend BOSH, since it was a pre-websockets workaround for long polling.

    I propose we litter [XEP-0156] with warnings explaining why it's
    insecure and should never be done, and obsolete it, instead
    referring people to the single host-meta method that [RFC-7395]
defines, which provides secure delegation when grabbed over HTTPS. In general, +1 to what you propose. Peter _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards <https://mail.jabber.org/mailman/listinfo/standards> Unsubscribe: standards-unsubscr...@xmpp.org <mailto:standards-unsubscr...@xmpp.org> _______________________________________________

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to