[Security] TLS Certificates Verification

Greg Hudson ghudson at MIT.EDU
Tue Aug 19 10:00:07 CDT 2008


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.




More information about the Security mailing list