[jdev] Re: s2s doubts

[Stephen Marquard]

Peter Saint-Andre wrote:

> On Wed, May 18, 2005 at 11:18:58AM -0700, 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.
> 
> I fail to see what anyone is making up here. TLS is documented in
> Section 5 of RFC 3920. Server dialback is documented in Section 8
> of RFC 3920. Stream features are documented in Section 4.6 of RFC
> 3920. Nowhere in RFC 3920 is it set forth that two servers MUST 
> NOT or SHOULD NOT complete dialback if they have completed TLS 
> (although RFC 3920 does say that two servers SHOULD NOT complete
> dialback if they have completed SASL). If you are suggesting that
> rfc3920bis be changed to so specify the relationship between TLS
> and dialback, that is one thing. But the spec as written does not
> forbid this behavior in any way.

TLS + Dialback (as implemented in j1 and j2) would seem to violate these 
rules in XMPP 5.1:

7. The initiating entity MUST validate the certificate presented by the 
receiving entity; see Certificate ValidationCertificate Validation 
regarding certificate validation procedures.

12. If the TLS negotiation is successful, the initiating entity MUST 
continue with SASL negotiation.

So in this regard, j1 & j2 are not XMPP-compliant. But then as they're 
already not XMPP compliant by not implementing SASL, this is nothing new.

Regards
Stephen