[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Tue Aug 19 22:56:11 CDT 2008

Greg Hudson wrote:

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

It does? Negotiate a reliable transport, start an XML stream, and 
upgrade the stream to encrypted via STARTTLS, just like we currently do 
for client-to-server streams. How is that enormously complex? Granted, 
the reliable transport might not be raw TCP -- it might be a direct or 
mediated bytestream (XEP-0065), an in-band bytestream (XEP-0047), or 
some other reliable transport. But I don't see how that makes the 
complexity enormous.

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

Like RFC 3923 perhaps? ;-)

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

In what sense is TLS necessarily tied to X.509 certs? There are various 
TLS ciphers, some of which use PGP keys, SRP, or other methods. Maybe 
those are extensions to TLS or TLS "hacks", but they do exist.

> 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'm glad to hear it. :)

> I will
> claim that if it's deployed 

In one particular client. So we don't even have experience across 
multiple implementations.

> and in moderate use today, 

I have not heard about any reports of how often it is used, what the 
user experience is, whether it can be hacked, etc.

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

Using TLS is not starting over -- it is re-using something that we 
already use for c2s and s2s streams, but in the context of e2e streams.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080819/1483b600/attachment.bin 

More information about the Security mailing list