Greg Hudson wrote:
the implementation complexity of XTLS sounds enormous compared to the implementationcomplexity 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 useX.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 willclaim 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.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
