"Eric Rescorla" wrote: > On Mon, Aug 18, 2008 at 7:20 AM, Jonathan Schleifer > <[EMAIL PROTECTED]> wrote: >> Am 18.08.2008 um 13:39 schrieb Dirk Meyer: >> >>> Yes, that is solution 1 for this problem. Each user can get a >>> certificate signed by the XMPP CA. But is that practical. I have not >>> tried to get a signature for my XMPP server yet, but how hard is it? >>> Every person who can use an IM client and register for an account >>> should be able to get a signed certificate. IMHO usability is the main >>> problem we have to keep in mind when trying to solve this. >> >> It's impossible for the average user to get a certificate. Only geeks will >> use encryption then. I still think we should pay the money needed for a >> cryptanalysis for ESessions and use that - that's crypto even my grandmother >> can use! All that hacky TLS for end-to-end stuff is more than >> userunfriendly. > > The method you use for establishing trust in credentials is largely > orthogonal to the protocol you're using. In particular, TLS is quite > compatible > with leap-of-faith type mechanisms. That's just not what's the standard > end-user clients use. It's true that TLS doesn't currently support an SAS, > but it wouldn't be that hard to add if it were determined that that's what > people wanted, and that's probably more efficient in the long run than > having an entirely separate security protocol for jabber alone.
Yes. TLS provides two things: a certificate chain to validate a certificate and a way to encrypt a session based on public and private keys. The later is something we need and it is well understood. So IMHO we should use it. The first one is crap: like Jonathan wrote: only geeks will send the key to a CA. So what we can do very easy is generate self signed certificates to use with TLS. Now we have encryption. We have one question left: does this self signed certificate belong to the person I want to talk to. Since we have no CA we need to find other ways. > Instead of talking about specific technologies, I would recommend > trying to figure out what interaction model you want to have. I.e., > what do you want people to do to determine that the person on the > other end of the line is the correct one? Right. After the TLS handshake I know the public key and the fingerprint of my peer. I also have my own key pair. How can we use that to verify the peer. First idea: send fingerprint over a different transport, e.g. mail. That sucks because fingerprints are not very userfriendly. So maybe a password (shared secret) to verify this? Maybe some sort of web of trust? >>> Yes, a key-pair and self-sign to make any TLS library happy. After >>> that we can create a web of trust outside the ssl library. I don't >>> know if this will work, but it could. >> >> Signing keys is nothing the average user will do. Never. > > They will if the software just does it. Right. One openssl command will generate a self-signed certificate. Simple and TLS is happy. > I must say, I find SAS fairly user unfriendly as well. At least with > a fingerprint type mechanism I can go out of band to someone's web > site and check the fingerprint. With SAS, I have to actually call > them on the phone. That is not an option for me. I want bots to talk to each other. They can not use the phone. Dirk -- "The early worm gets eaten by the bird, so sleep late."
