[Standards] various rfc3920bis feedback

Philipp Hancke fippo at goodadvice.pages.de
Tue Feb 24 11:05:50 UTC 2009


Dave Cridland wrote:
>>>> * bidirectional s2s could be announced in <stream:features> sent
>>>>   right after the opening <stream> tag from the initiator.
>>
>> Unidirectional S2S has been around for too long, I do not see a real
>> gain in fixing that now.
>>
>> This was discussed in Feb 2004 on the XMPPWG list:
>> http://mail.jabber.org/pipermail/xmppwg/2004-February/002020.html
>> However, I have not seen bidirectional S2S in the last five years
>> and 3920bis (4.4) includes the consensus (?) that s2s is
>> unidirectional.
>>
>>
> *nods* Indeed. I think we've reached the point where we need signalling 
> to enable it. And I defintiely think we need to enable it.

Why need?

There is a potential for problems here, such as servers which are not
reconnectible. But that is a problem with EXTERNAL already, where you
can send messages without being able to receive any.

>>>> * connection reuse for multiple s2s links would be a very useful
>>>>   feature, ask Dave for details
>>> Piggybacking.
>>
>> Which is subtly broken in RFC 3920 - at least 50% of it.
>> <host-unknown/> makes 'target piggybacking' (different to)
>> unusable, as you risk the entire stream.
>>
>>
> *nods* Agreed.

Luckily the last version of 220 already introduced the way to fix
that - without actually solving the problem :-)

>>> What I'd like to do here is use the dialback elements as an 
>>> authorization request mechanism.
>>
>> Dialback is 50% authorization request, 50% key verification.
>> Splitting it up accordingly simplifies the description.
>>
>>
> Yes, I think so too. In fact, we can elide the actual key if we know the 
> receiver won't ever use it.

I think sending the key always is the easier way, being more-or-less
backward compatible.

>>> In fact, by specifying how to do this without actually doing 
>>> dialbacks, but instead by verifying the identity of the sender based 
>>> on the X.509 cert, we can actually get rid of SASL EXTERNAL and just 
>>> use X.509 only, which eliminates the difference between the "first" 
>>> authorization and subsequent ones.
>>
>> There is no 'subsequent' auth with 0178 yet, is there?
>> There are three different options:
>> 1) do 0178 and add subsequent auth (including graceful failure)
>> 2) do 0178 for the first authorization and use piggybacking (with
>>    graceful failure again) for subsequent authorization... err...
>>    verification
>> 3) ignore any 0178 offers and do piggybacking for everything.
>>    Might be a problem if servers require 0178 and really mean it.
>>
>>
> I'm thinking we aim for (3), with signalling as required.

*nod*
Might be a problem if a server requires EXTERNAL, but this is rare in
uncontrolled environments anyway.

That would make 0178 c2s-only and it could be merged with 0257 somehow.

>>> The dialback flow then becomes:
>>>
>>> 1) O2R : <db:result/>
>>> 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT
>>
>> Assumes that the originating server does not check with the
>> authoritative server that the receiving server has verified
>> the key.
>>
>>
> Right - I don't expect this to be the case - I don't see what the point 
> would be - but I've not had the time to try this optimization out in the 
> field, yet.

"You're telling me the key is valid without checking it? Then you must
be lying."
I think dialback was not designed to protect from that anyway.

>>> 3) R: Connect to A
>>> 4) R2A: Establish TLS.
>>> 5) R2A: If A's certificate matches O's, goto ACCEPT
>>
>> Nice optimization ;-)
>>
>>
> It saves a round-trip or two.
> 
>>> 6) R2A: <db:verify/>
>>> 7) A2R: <db:verify/>, goto ACCEPT
>>> ACCEPT:
>>> 8) R2O: Authorize O as requested domain, send <db:result/>
> 
> Here's a question - if there is TLS involved (thus IP spoofing is, as I 
> udnerstand things, impossible), and the SRV records include the 
> originator, can we also elide the R2A session entirely?

There are two problems with that approach:
1) you do not know if the remote server is up and listening for
    connections. See above.
2) an evil user on the remote system (other than the user who is
    running the jabber server) who is able to open connection to
    remote servers.

I do not think (2) is a real problem, especially not when certificates
are used.

Philipp



More information about the Standards mailing list