[Standards] various rfc3920bis feedback

Dave Cridland dave at cridland.net
Tue Feb 24 11:18:17 UTC 2009

On Tue Feb 24 11:05:50 2009, Philipp Hancke wrote:
>>> 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.
That's possible. But then, 0178 should get merged with rfc3920bis.

>>>> The dialback flow then becomes:
>>>> 1) O2R : <db:result/>
>>>> 2) R: If TLS, and X.509 cert matches requested domain, goto  
>>> 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."

But it makes no sense. If the remote end doesn't validate the key,  
but authorizes you anyway, then you're authorized, and it doesn't  
matter whether or not you think they did it right.

> I think dialback was not designed to protect from that anyway.
Protect from what?

>>>> 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.

If a trustworthy certificate is used, then we don't need to dialback,  
certainly. (And trustworthy can mean "we've dialled back before and  
we know this one"). Without that, then scenario (2) is possible.

So it's not really worth persuing that one.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list