[Security] TLS Certificates Verification

Jonathan Dickinson jonathanD at k2.com
Tue Aug 19 16:12:47 CDT 2008


Requiring serverless messaging is a deceiving lure.

What if the client is behind a symmetric NAT? Or some NAT that simply doesn't working with STUN (or ICE/SIP/whatever)? They can't open a encrypted session?

It's a great idea though. My XEP literature isn't really that great for stuff not on the official list (and I am still working through the official list itself). But something that may work with this is as follows:

If there is a XEP that defines a stream in a stream (I think there was), one would open a new stream to a remote contact and simply do a starttls. In the case that both clients can be accessed (if they are behind a supporting NAT, or have a public IP) they can open the stream to each other directly and do a starttls.

-----Original Message-----
From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On Behalf Of Dirk Meyer
Sent: Tuesday, August 19, 2008 11:02 PM
To: XMPP Security
Subject: Re: [Security] TLS Certificates Verification

Jonathan Schleifer wrote:
> Jonathan Dickinson <jonathanD at k2.com> wrote:
>
>> (compared to making
>> a new standard which would have no implementations).
>
> ESessions *HAS* implementations! That's the point I bring up again
> and again against reinventing the wheel and doing something with TLS
> now!

One point is that we may also have serverless messaging. In that case
we already open a new stream and get TLS for free. The idea was to
have one way for both serverless and server based messaging.

> Now you're even talk about breaking XMPP Core compatibility?

He wrote that when we would update client-server communication. Let us
do that someday else. :) Right now we only need client to client
encryption. That does not involve any core changes.

> And libotr can't handle arbitrary data, just messages.

And out. I need iq stanzas to be encrypted, too. Everything else is
useless for me. In fact, 90% of the data I plan to send are iq
stanzas.

> For which it will add HTML escapes if it's plaintext.

And out again. The last 10% I will use for messages are more or less
just pubsub messages. HTML does not belong there. Yes, I plan to use
client to client pubsub.


Dirk

--
And on the seventh day, He exited from append mode.


More information about the Security mailing list