On Tue, 2008-08-19 at 10:09 +0200, Jonathan Schleifer wrote: > Am 18.08.2008 um 23:21 schrieb Peter Saint-Andre: > > > Except that it's an unanalyzed technology. > > But it wasn't analyzed with IM in mind, but stuff like HTTPS or IMAPS.
This is true. Running TLS on top of an XMPP stanza stream might sound like it should be automatically as secure as TLS is over TCP, but I don't think it's likely to be that simple. Moreover, the implementation complexity of XTLS sounds enormous compared to the implementation complexity of ESessions; it doesn't do much good to have a bulletproof-on-paper security protocol if all of the implementations are flawed, or if they don't exist. Moreover, a lot of security holes come from using a security subsystem which doesn't quite meet the needs of the application. TLS chose to use X.509 certificates rather than create its own public key formats. That may have been a necessary choice, but X.509 certificates were not designed with securing DNS domains in mind, so it hasn't been a perfect fit. X.509 certificates are also very complicated (much of that complexity having nothing to do with TLS's requirements), leading to a lot of "deep, dark, secret code that no one understands" in the implementation of a TLS stack. Using an existing, analyzed security primitive has benefits, but it can also have some pretty severe costs. I'm not going to claim that ESessions is likely to be foolproof. I will claim that if it's deployed and in moderate use today, and fits the security needs of end-to-end XMPP encryption, then we are much more likely to see successful secure end-to-end XMPP encryption deployment in ten years if you we with Esessions (fixing its problems as they are discovered) than we are by scrapping it and starting over with XTLS.
