[Security] e2e TLS

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 13 09:16:11 CDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 xmpp at ietf.org 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

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw8dSsACgkQNL8k5A2w/vyzpACfRm7dwa/+ew/+kZq2NmpkLOXF
d+wAoO14PXBk0qrxEVagnLiMvuXD0GvP
=MPPe
-----END PGP SIGNATURE-----


More information about the Security mailing list