[Security] [Jingle] Jingle / e2e security (1)

Pavel Simerda pavlix at pavlix.net
Wed Feb 11 08:42:26 CST 2009


On Wed, 11 Feb 2009 12:51:25 +0100
Earl <Large.Files at gmx.net> wrote:

> I see several problems with self-generated X.509 certs.
>
> I doubt that Joe or Suzy Normal has the ability to generate a
> self-signed cert.

The certs are generated by computers, not with paper & pencil.
Generating a self-singed cert is roughly as easy as generating
any other sort of a public key, for the computer.

> All the average users that I know are *not*
> capable of generating a self-signed cert with OpenSSL.

They never need.

> Skype is an "install and it just works" client.  This is how
> Jabber/XMPP clients also have to be.

Comparing to skype is nice, but you are intermixing technology and
user experience. You can only compare technology with technology and
user experience with user experience (and discuss relations).

> If I remember correctly, OpenSSL defaults are miserable and need
> command line flags or changes in config files.

Still the same misinterpretation of picture of the user's interface.

> It does not matter
> since SSL can be trivially broken by the MITM.

You have stated it several times with no proof or valid references. Now
you're actually starting spamming the channel with an unconfirmed and
probably misunderstood claim, even though you have already read
reactions from others.

Please don't do it.

> As Pavel mentioned, a container holding public keys is not magically
> secure.

Not only as Pavel mentioned. I believe it's a well-understood by the
security ML people, where most information in this thread fit better
than to Jingle.

That's why I decided to crosspost... and I kindly ask interested
parties to subscribe to the Security mailing list and continue there.

More, I propose that people that have something to say about ZRTP and
TLS comparison, get a login to the XMPP wiki and do it on a wiki page:

http://wiki.xmpp.org/web/TLS_versus_ZRTP

This way we can keep it for later reference. Please also provide
links to documents where the details can be found.

> As long as ZRTP uses a recent and modern hash algorithm and sufficent
> number of bits, the probability of it not detecting a MITM is quite
> low.

Please provide a valid reference for this claim.

> The average user has no problem with ZRTP and its SAS - and in my
> opinion this method is preferred for Jabber/XMPP security.

Yep, that is your opinion.

> It's easy to use and much more secure than X.509 / SSL while not
> costing any more money or development time. 

Provide valid reference for the first claim... that ZRTP is much secure
than X.509 / SSL. We can discuss development time later.

> SIP-COMMUICATOR just
> demonstrated ZRTP this last weekend at FOSDEM 2009.

Good for them, we might learn a lot from an already-used implementation.

> They
> started a demo each morning + the Audio-Video demo lasted the entire
> day, non-stop. No loss of sync, no degradation, low latency, no
> crashes, and great quality.

I see no clear relation between these observations and the claims you
are defending.

> Twinkle is another program with internal
> ZRTP.

Thanks for the info.

> ZRTP is here now, it is not pie-in-the-sky, it works, it is stable,

I don't see a single well-tested XMPP application with ZRTP support.

> it is very easy to use even for newbies,

ZRTP is a protocol, newbies usually don't read protocol specifications.

> and it offers *much* more
> security than other proposals.

I've seen this unconfirmed claim already.

> The next version should be close to
> final release.

Thanks.

> Its crypto engine is exactly what Jabber/XMPP needs to
> negotiate keys for secure file transfer.

ZRTP protocol includes a crypto engine?

>  Using this engine for
> voice, video, file transfer, and
> chat will save developer's time and result in optimum security, while
> making a simple-to-use client for beginners and experts.

This looks more like a an advertisement for a product... but, ok.

Optimum security is not something you can force. Actually there is no
globally optimal security at all.

> 
> My 2 cents of opinion.

Unfortunately, mere opinions (right or wrong) don't help with protocol
design, nor to clarify a particular area to other discussing people.

Pavel

> Earl
> 
> Peter Saint-Andre wrote:
> > Stephen Pendleton wrote:
> >   
> >> I'm not a security expert, but I would argue that on a practical
> >> level the best part of zrtp is that it doesn't requre a PKI. It
> >> would be nice to have a solution that didnt require a PKI (and
> >> isn't patent encumbered). 
> >
> > TLS, DTLS, SRTP, etc. do not require CA-issued certificates (in
> > fact TLS can be used with Secure Remote Password or OpenPGP), but
> > our working assumption is that clients would generate self-signed
> > X.509 certs for users. Whether that qualifies as PKI depends on
> > your definition.
> >
> > /psa
> >   
> 


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net


More information about the Security mailing list