On Tue, Aug 19, 2008 at 1:13 AM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > Am 18.08.2008 um 23:34 schrieb Eric Rescorla: > >> (2) What protocol it's embodied in. > > Well, what I don't understand: We already have ESessions
Yes, I've noticed we're all using that. >. Why do we need > another protocol now? I'm not saying that one does. I'm saying that it's traditional in systems design to actually do requirements before one jumps to a solution. > ESessions offers nearly everything you can think of. > It offers public keys, but you can also use secrets instead of > public/private keys. Hmm... Is this the most recent version? http://www.xmpp.org/extensions/xep-0116.html I've just skimmed it, but the list of things it appears to be missing that are already in TLS includes: - Support for ECC - Support for RSA - Any form of session resumption - An extensions framework - Support for AEAD ciphers - A PAKE mode. Oh, yeah, is there some writeup of how the stanzas are actually protected once you've established the keys? I see how you negotiate the *encryption* algorithm but not the integrity algorithm and I don't see how you use either to protect the actual traffic. Maybe I'm just reading the wrong document. > IMO, it offers all we need. All that's missing is a cryptanalysis for it. That's not exactly trivial. 13 years after SSLv3 was designed we're *still* tuning TLS. Now, if you want, you can say that ESessions is perfect out of the box, but given that no COMSEC protocol I've ever seen has had that property, I find that extraordinarily implausible. Look, I'm not trying to sell TLS to XMPP; it doesn't matter to me much what XMPP does. But if you want to provide a solution that users will actually find tolerable, it seems to me that it would be good to actually assess what functionality you want the system to provide and *then* ask how it can best be provided, rather than starting with a given protocol and say "prove to me it's not good enough". -Ekr
