[Operators] requiring channel encryption

Brian Cully bcully at gmail.com
Sat May 3 01:54:59 CDT 2008

On 30-Apr-2008, at 12:02, Peter Saint-Andre wrote:

> Brian Cully wrote:
>>    I think mandating TLS for c2s is a mistake. At the edges of the
>> network, it should really be up to the local operators and their
>> conditions. There are /lots/ of networks that have absolutely no need
>> for it.
> The jabber.org admin team makes decisions only for the jabber.org
> service, not the network as a whole. Even if we require c2s at our
> service, other services are under no compulsion to do so.

	I apologize. I completely misread what you were saying. You're, of  
course, correct.

>>    s2s is a different animal. If you allow self-signed certs, I'm  
>> sure
>> compliance wouldn't be much of a problem. It's useful to encrypt, but
>> without authentication, I'm not sure if it's all that much of a net- 
>> win.
>> Man-in-the-middle becomes trivial, so you'd really only stop the  
>> bottom
>> rung.
> Is it trivial? Do the servers you connect to via ssh use certs that  
> are
> issued by a CA? Probably not -- but your ssh app will warn you if the
> cert changes.

	The difference is that there's no automata doing the setup or  
verification. When you have to rely on idiot computers, trust goes out  
the window. It might be useful to require that jabber implementations  
reject communication when a key changes unless specifically authorized  
by someone. However, even in that scenario, you're just playing games  
with time, and you can still lose badly. This is, again, less an issue  
with SSH, due mostly to the amount of work I do when I build or  
connect to the system in the first place.

>> I'm really not sure what the correct solution is
>> here. I don't want to out the gal putting up ejabberd on a server  
>> in her
>> basement from the process,
> Can't she create a self-signed cert?

	Self-signed is meaningless from a trust perspective, which is how  
I've been attempting to attack this problem. For tests and easily  
foiled encryption it's fine, but for secure and trustable networks it  
is not. Dialback also doesn't alleviate this problem, as DNS can be  

>> but if we're going to go the encryption/trust
>> route, it should be relatively secure.
> Definitions of "secure" vary. What's yours? :)

	Personally? I don't really care. If I want secure communications I've  
already negotiated my keys outside of the jabber protocol. That said,  
I'm probably not a good example. ;)

	However, the security needs of firms vary pretty wildly. Any  
requirements on s2s should take that into account as much as possible.

	I almost wonder if the c2s approach might work: when connecting to a  
foreign XMPP server, present a dialog to the user asking if they'd  
like to trust a key. This way you can leave it in their hands, and in  
some ways wash your hands of the situation.

	Maybe Jane doesn't really care that gmail isn't encrypted, but Bob  
does. Or Carol won't connect to a self-signed spork.org account, but  
Dave thinks it's fine.

	On the server side you could also make these determinations, but in  
the most lax case you connect to everything and remember the cert (or  
lack), and when a user makes a connection to a foreign xmpp server,  
show them the cert you saved (or didn't).

	Of course, server operators should be allowed to mandate their needs  
(sorry Goldman Sachs employees, you don't get to choose whether or not  
J.P. Morgan is properly authenticated!).

> Perhaps. I don't think that TLS is a magic solution to building trust,
> but it can't hurt. Plus if we can advertise that we have s2s  
> encryption
> across most of the public network, that will help build trust from the
> outside.

	At the very least, it will prevent trivial interception of what we  
all hope to be very popular channels of communication.

>>    The only problems I see are what to do with XMPP hosting  
>> providers.
>> If you want to host a large number of domains, requiring TLS on s2s  
>> can
>> get really unwieldy. DNS issues make trusting SRV records  
>> problematic as
>> well. So, again, no better solution.
> Yes, that is a big problem, and one reason why Google Talk doesn't  
> do TLS.

	I'm of the opinion that XMPP hosting will be almost as big as Web  
hosting. AIM is the GeoCities of 2005. People will want their own  
domains and more control over service use. So, naturally, this is  
going to become a bigger problem.


More information about the Operators mailing list