Subject: [xmpp] Fwd: Re: [Security] e2e TLS

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Jul 2010 08:17:24 -0600

This message (sent to the [email-masked] list) might be of interest
here...

/psa

-------- Original Message --------
Subject: Re: [Security] e2e TLS
Date: Tue, 13 Jul 2010 08:16:11 -0600
From: Peter Saint-Andre <[email-masked]>
Reply-To: XMPP Security <[email-masked]>
To: [email-masked]

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?

http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption

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 [email-masked] list. Links here:

http://tools.ietf.org/wg/xmpp/

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.

Peter