On Wed, May 18, 2005 at 09:10:26PM +0200, Stephen Marquard wrote: > 3. Dialback + TLS is a sensible extension of dialback + stream features > for supporting TLS, even though strictly speaking it violates XMPP > (which requires TLS to be used with SASL). It's sensible in that it > doesn't break connecting to servers that don't support TLS, and servers > that talk to dialback+TLS-enabled servers should simply look at the > stream features offered to see if SASL is available or not. If not, they > can choose not to use TLS at all, to remain strictly XMPP compliant.
Strict XMPP compliance at the price of unencrypted s2s connections seems rather a hollow victory, no? Look, we'd all rather have encrypted s2s connections. Ideally, per RFC 3920, such connections would also be authenticated via SASL, since we know that dialback provides weak verification only, and not true authentication. But it may be that until we figure out the CA issue, few Jabber/XMPP servers on the public network will have domain-level certificates that can be traced back to a CA (i.e., non-self-signed certificates). Throwing out the baby (encrypted s2s) with the bathwater strikes me as counter-productive. So while I would really like to see all server implementations support SASL, if the best we can do for a while is dialback after TLS rather than SASL after TLS, then that at least is an improvement. /psa _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
