[jadmin] trusted federation

[Johansson Olle E]

18 jan 2008 kl. 17.50 skrev Peter Saint-Andre:

> Tomasz Sterna wrote:
>> On Cz, 2008-01-17 at 16:51 -0700, Peter Saint-Andre wrote:
>>> I have posted some thoughts on upgrading the Jabber network to  
>>> encrypted-only s2s here:
>>>
>>> https://stpeter.im/?p=2136
>> Could you describe more verbosely why CA signed certs are better than
>> self-signed + dialback?
>
> Well, "better" depends on your perspective. :)
>
> Let's say you are an investment bank. You might want to federate  
> only with other companies in the financial sector -- banks, rating  
> agencies, hedge funds, the SEC, etc. And you might use a common CA  
> for that.
>
> But if you a service provider like NTT, you might want to federate  
> more broadly with much of the open XMPP network. However, you might  
> want to do so only with XMPP services that have at least a Class 1  
> certificate from a trusted root.
>
> It's not for us to dictate service policies. But we need to at least  
> offer a range of options that services can choose from, and make  
> those choices clearer.
>
> I agree with you that for the purpose of the open network, TLS 
> +dialback has most of the properties that most services probably  
> want. So I think we need to document that option better and make  
> sure that all the servers implement it correctly.
>
>> We need a CA to verify certs given over https and similar protocols.
>
> Do we?
>
>> But with XMPP we have dialback to verify sender. It works now really
>> well.
>
> Aha, I had not thought of it that way.
>
> In a way, TLS+dialback is similar to what people already accept in a  
> protocol such as ssh. How many of you server admins independently  
> check the fingerprint when you connect to a new unix machine?  
> Probably not many. But if the fingerprint changes for the next  
> session then that raises a red flag. We could do something similar  
> with s2s connections. But that would require better reporting in  
> existing implementations. I'm not yet sure what form that reporting  
> might take, but I think that would be good to explore.
>
>> Making the entry barrier to join XMPP network higher isn't going to  
>> make
>> XMPP adoption quicker.
>> We have been working very hard to lower the entry barrier in the  
>> past.
>
> We have also been working to lower the barrier to obtain Class 1  
> certificates via
>
>> We could consider the following model though:
>> - if the presented cert is trusted - done, we have a connection
>> - if the cert is self-signed - verify the given server name with
>> dialback
>> - if the cert is invalid or not present - drop connection
>> This way we could have a secure, trusted network, with low entry  
>> barrier
>> and no third party signature needed to join.
>
> Yes, I think that is a good next step on the way to trusted  
> federation. And it might even be good enough for a long time (until  
> the spammers figure out DNS poisoning on a wide scale -- but then  
> we're pretty much screwed anyway).
>
> I will work to update XEP-0220 (server dialback) so that it  
> documents TLS+dialback more completely.

There's also an option of using DNSsec and storing self-signed  
certificates in the DNS. There's a hack for SSH around somewhere where  
SSH accepts server keys that can also be retrieved in a certified DNS  
zone.

That could be another solution to add to the mix.

/O