Jonathan Schleifer wrote:
Am 20.08.2008 um 19:08 schrieb Jonathan Dickinson:Good suggestion. Seeing as Google is one of the sponsors I don't see why they wouldn't.Yeah, and if we have a cryptanalysis,
That is a very big if.
what reasons are there against ESessions?
TLS has undergone many many years of cryptanalysis, hacking attempts, and incremental improvement. One crytpanalysis does not make a secure protocol.
It's already implemented and Brendan Taylor already said to port his Python implementation to C so others can use it, so we will have a library even easier to use as libotr! Would be even far easier for devs to use that lib than to play around with some TLS lib,
Excuse me, but we already "play around" with TLS libs -- unless you hadn't noticed, that's how we do channel encryption right now, and every Jabber client under the sun already supports it. It's very attractive to use the same underlying technology for encryption of c2s, s2s, and e2e streams (whether the latter are link-local or happen over TCP, XMPP, or whatever).
just pass the stanza to the lib and get the encrypted one back :).
And that is different from TLS how?Jonathan, you don't seem to be listening very well. I suggest that you stop beating the ESessions drum for just a little while and take a bit of a break to reflect on ekr's posts, read the relevant specs, and think seriously about how we could have e2e pretty much *today* in all clients using TLS-over-XMPP, reuse *any* existing TLS library, and incrementally add new features (e.g., SAS) to TLS if we need them (thus benefiting the entire Internet community).
And that's not even to get into the Layer 8 issues of what the IETF security mafia might find acceptable -- RFC 3921 requires support for RFC 3923 and we need to substitute something reasonable for that ugly ugly S/MIME stuff that no one has ever implemented and no one ever will.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
