XSF Discussion - 2022-02-13

moparisthebest, valid points indeed. i'd still really like to avoid piling more stuff on to HTTPS reliance, and agree that putting it anywhere near experimental will likely get it adopted by someone. for comparison, i guess matrix's point 3 for s2s resolution is applicable to all this chatter .. https://spec.matrix.org/v1.2/server-server-api/#resolving-server-names skimming through it, once the HTTPS well-known endpoint (on the requested domain) has delegated to another domain, then further cert validation will be for that delegated_domain (as opposed to the original requested domain)

maybe this helps ... maybe not ... but when my ISP desides to let me with no service nothing http realed works but somehow xmpp keeps working, my users send and receive message with no issues (http uploads do not work when that happends) ... so ... have this in mind, not reinventing the wheel over http is not a bug, it's a feature

moparisthebest, I am not sure if it is guaranteed that we will be with both things forever, and even if, I am not sure if it would be a problem. and I also believe you can't prevent it from happening

maybe we need to define what both things here are, so that we don't talk past each other: secureed information of an XMPPs service's endpoint(s), placed either in DNS or served via HTTP(S). That correct?

What exactly is the issue with srv that get's solved by switching to https?

Possibly that it isn’t accessible in the web sandbox, but we have XEP-0156 for that.

flow: yes that's right

mdosch: there are a few more, but the #1 issue I don't see a way around is simply that dnssec isn't widely deployed or even usable on domains like .im

Does it matter as long as you authenticate with the service and check it's cert?

mdosch: impossible for websocket and Bosh, and secure but not ideal for hosted XMPP services (no support for secure delegation)

Other issues: no transport security without sending all your queries directly to cloudflare/Google, impossible to carry additional info like key pinning (think DANE)

junaid: thanks for the link, kind of odd they decided for a mix of srv and .well-known for a brand new protocol....

xmpp-js is no longer vulnerable to _xmppconnect !

xmpp.js 🙂

Sorry, and thanks :)

sonny: sorry haven't got to respond to issue yet, I think leaving 156 around as just a registry for additional rel= definitions like Bosh makes sense, fyi I plan to add more like websocket-s2s and quic c2s and s2s, but I could also see arguments for putting those in their own xep, do you have opinions?