[jdev] Re: s2s doubts

[Peter Saint-Andre]

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