[jdev] Re: TLS and self-signed certs

[Peter Saint-Andre]

In article <20041118175148.GH29336 at serwis2.beta>,
 Jacek Konieczny <jajcus at bnet.pl> wrote:

> On Thu, Nov 18, 2004 at 09:33:05AM -0800, JD Conley wrote:
> > If an attacker attempts to connect and provides a certificate that is
> > not on record for the host they are claiming to be, a dialback is
> > performed against the authority of the host.  The attacker, unless they
> > have control of DNS or the other host's network, is then rejected as the
> > dialback authority would produce a certificate that is not the same as
> > the attacker's.
> 
> But the attacker hast to take over the DNS only once. After that his
> certificate is "trusted" and he can use the faked domain without
> problems. With pure dialback he would have to keep the DNS compromised
> all the time he wants to use the faked domain.

Very good point.

As I mentioned in my blog the other day [1], I tend to think that we 
will see islands (or archipelagoes) of federation, initially by 
industry. So certain financial companies will come to agreement on how 
they will do XMPP interop (perhaps they have a trusted CA for their 
industry), healthcare companies will have their own agreements, maybe 
some big ISPs will have their own business agreements, etc. What we're 
really talking about in this thread is s2s interop on the public jabber 
network, so that amessage.de can securely connect to myjabber.net and so 
on. If we limit the scope to the public network, we may find that the 
potential solution-set is quite different than if we were trying to 
convince Wall Street banks to connect to the public network (which, I 
have to tell you, ain't going to happen for a long time, if ever).

I don't have the answers to how we'll do this, and I am no security 
expert. Possible avenues to explore include a root CA for the public 
jabber network, webs of trust among server admins (I trust Matthias 
because I've met him in person, he seems like a trustworthy person, his 
server sends all the right protocols, etc.), reputation systems for 
servers, and probably lots of other things that I don't know about. As 
JEP-0139 [2] said:

1. Rough consensus and running code are superior to "perfect" solutions
2. Security measures that cannot or will not be implemented are useless
3. Iteration works better than trying to define all solutions up front

Those seem like good principles. Perhaps the first step, as mentioned in 
JEP-0139, is to define the threat model. I've been meaning to write up a 
first pass at a threat model document, but haven't gotten to it yet. 

/psa

[1] http://www.saint-andre.com/blog/2004-11.html#2004-11-15T20:13
[2] http://www.jabber.org/jeps/jep-0139.html