[jdev] Re: s2s doubts

Stephen Marquard scm at marquard.net
Wed May 18 14:10:26 CDT 2005


Justin Karneges wrote:
> On Wednesday 18 May 2005 09:42 am, Stephen Marquard wrote:
> 
>>Justin Karneges wrote:
>>
>>>If this was meant to be possible, it certainly isn't clear in RFC 3920. 
>>>Is this an extension documented somewhere?
>>
>>You do TLS as documented for streams (if advertised as a stream
>>feature), and then dialback as documented. TLS doesn't add much
>>additional complexity - the only subtlety is to wait for TLS to complete
>>once it's started before sending any dialback packets.
> 
> The spec does not discuss dialback with TLS, or even <stream:features> for 
> that matter.  My problem with what you describe is that it would probably 
> cause breakage between jabberd and my own server implementation which was 
> created according to the spec.  Please don't make stuff up.  If we really 
> want dialback + TLS, this _needs_ to be documented in the RFC.

Some observations:

1. None of the open source jabber servers (j1, j2, ejabberd, etc.) are 
XMPP compliant in all regards - c/f http://www.jabber.org/admin/jsc/. 
XMPP 14.7 says "At a minimum, all implementations MUST support ... SASL, 
TLS, TLS plus SASL EXTERNAL".

2. Compliant XMPP servers that want to interoperate on the public jabber 
network already need to assume that they may be talking to jabber 
servers that don't support all of XMPP.

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.

4. Dialback + TLS has been independently implemented in j1 and j2 with 
no operational problems so far attributed to its use on the public 
jabber network.

5. The main barrier to TLS+SASL on the public jabber network seems to be 
the long-standing debate about which CAs should and shouldn't be 
trusted. This seems to be come up about every 6 months.

So if everyone with an interest in the public jabber network could agree 
on 5, then we could all get on with implementing TLS+SASL support in a 
way which had some practical benefit outside intranet deployments, and 
produce XMPP-compliant servers.

Right now, TLS+Dialback is providing the benefit of encrypting s2s 
streams while the larger question gets sorted out. If necessary it could 
be written up in a JEP, but it's not that complex.

Regards
Stephen




More information about the JDev mailing list