[Security] [xmpp] Fwd: Re: e2e TLS
public at stevenroddis.com
Tue Jul 13 21:09:05 CDT 2010
You raise some points however take the following scenario:
Encrypted File Transfer (e2e):
The messages sent from user to user should be protected c2s over TLS.
If c2s isn't encrypted, then chat messages won't be secured. The /could/
extend to s2s communications needing to be secure as well, however s2s
communication is outside of the end user's control to a point however they
could only to talk with users on the same host.
What I'm proposing is an option equal to the security of the text messages
sent from client to server [to server] to client.
Where file transfer keys are sent via stanzas before the e2e communication.
Which makes sense, you trust the XMPP server for authentication and
One could argue, what's the point of manual verification when XMPP relies on
a server for "text stuff".
I'd like to hear your thoughts and anyone else's :)
P.S. By chat in the last message I just meant any conversations, muc or
On 14 July 2010 00:17, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> This message (sent to the security at xmpp.org list) might be of interest
> -------- Original Message --------
> Subject: Re: [Security] e2e TLS
> Date: Tue, 13 Jul 2010 08:16:11 -0600
> From: Peter Saint-Andre <stpeter at stpeter.im>
> Reply-To: XMPP Security <security at xmpp.org>
> To: security at xmpp.org
> On 7/13/10 1:00 AM, Steven Roddis wrote:
> > From what I've read the current idea is to do manual authentication of
> > the keys needed for end-to-end encryption via TLS.
> Are you talking about the following I-D?
> If so, it would be helpful if you could reference specific text in that
> document. Also, note that this topic is in scope for the IETF's XMPP WG
> so it would be helpful to post to the xmpp at ietf.org list. Links here:
> I'll forward my reply to that list, as well.
> More comments inline.
> > 1. Send keys over XMPP
> > If the user agent is required to only use e2e (and thus communicate
> > keys) when c2s is secure then the following requirement isn't needed.
> Naturally it's a good idea to secure your connection to your server, but
> that doesn't necessarily protect the s2s connection to your buddy's
> server, nor the connection between his server and his client.
> > (Recommended)
> > keys are sent each time when a e2e TLS connection will be taken place,
> > and no caching to take place, because there is a possibly for the keys
> > to be transferred over an insecure channel and cached for use where
> > there is a secure one. Impact and attack made in the past, can still
> > take place after the client has switched to a secure connection.
> See above.
> > *Easy
> > *Automatic (great)
> > *secure if you trust c2s
> I don't see that.
> > *requires c2s
> Well, XMPP is almost always deployed as with an architecture of
> distributed clients and servers, so in that model c2s is "required" in
> some sense.
> > 2. Allow the user to validate the certificate
> > *Hard, confusing to some users.
> I'd change "some" to "most". :)
> > *Requires out of band communication
> Probably (meet in person, exchange information via encrypted email, etc.).
> > *user interaction is required
> It's hard to see how anyone will have high security if no user
> interaction whatsover is involved.
> > *increased security, doesn't rely on a 3rd party server, imagine e2e
> > chat as well.
> By "chat" do you mean multi-party communication?
> > *Will work if the server goes down
> If your server goes down then you won't be able to communicate anyway
> (in a distributed client-server architecture).
> > I propose a mixture of both options:
> > Ask the user if they want to manually authenticate, by what ever method,
> > fingerprints, socialist millionaire protocol etc. the more the merrier.
> > And provide an easy and make this choice the default, an automatic
> > verification through the server.
> > This allows the user increased control over the validation process if
> > they want it
> > But also lets users do things the easy way, and still be secure.
> I am coming to think that "easy" and "secure" are mutually exclusive.
> xmpp mailing list
> xmpp at ietf.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Security