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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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.

Reply via email to