[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Tue Aug 19 12:24:39 CDT 2008

On Tue, Aug 19, 2008 at 8:00 AM, Greg Hudson <ghudson at mit.edu> wrote:
> 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.

No, but the new security issues are basically the same as those that
ESessions is going to have, namely the interaction with the XMPP

> Moreover, the implementation
> complexity of XTLS sounds enormous compared to the implementation
> complexity of ESessions;

Man, if I had a nickel for every time I'd heard someone think it was a
great idea
to invent their own security protocol cause TLS is too complicated. The
reason that TLS is complicated is that new features have been added to
support real-world needs. This is what happens when protocols get
mature. I'm not saying that TLS is perfect, but I invite you to tell me what
features of TLS you can swear you're never going to want.

Moreover, 90+% of the implementation complexity of XTLS is going to be
in the TLS stack, which you already had to absorb because that's what
you're using for a channel security protocol already.

> 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.

But again, you've already absorbed those costs with TLS.


More information about the Security mailing list