/me takes a deep breath Dave Cridland wrote:
On Tue Aug 19 22:19:31 2008, Jonathan Schleifer wrote:"Eric Rescorla" <[EMAIL PROTECTED]> wrote:> There's something truly ironic about someone lobbying for an entirely > new and unanalyzed cryptographic protocol suggesting that using the > most widely implemented crypto protocol in the world would be > reinventing the wheel. There would be several changes needed as already stated on this list. And new XEPs would need to be created. XEPs for stuff for which already XEPs exist. If that's not reinventing, I don't know.Actually, the XTLS proposal in its current form consists of XEP-0246, which is virtually all boilerplate, and just says "negotiate a XMPP stream", and XEP-0247, which says "figure out a way to talk to each other using Jingle, first".So there's new stuff, sure, but it's not reinventing by any stretch - this stuff can be used and reused in multiple ways, not just for end-to-end authentication and privacy. In fact, XEP-0246 just abstracts out that part of the link-local messaging we've had for ages.Inventing ESessions out of the blue most certainly *is* reinventing, or at the very least was at the time. It's hard to suggest in any reasonable way that ESessions is going to be as strong, cryptographically, as TLS is; it's similarly hard to propose that the implementations of it will be as hardened as the likes of OpenSSL.Admittedly, it's painful throwing away that volume of work, but I think it's the right choice here.
I agree this is painful. Ian Paterson put a *lot* of work into ESessions but did a bit as well, and I don't like to throw that away. However, I have slowly come to the same conclusion: it would be better to re-use TLS for end-to-end streams (and we already use it for c2s and s2s streams so it's not that much of a stretch to use it for the e2e case). It's never easy to admit that sunk costs are simply sunk, but sometimes that's the best thing to do.
If the additional properties of ESessions are of interest, we could of course work toward putting them into TLS - deniability in TLS would be instantly applicable to any other protocol which needs it, for instance. That might include SIP, I suppose.
As mentioned, I don't think deniability has any real meaning (do you think purely cryptographic deniability would hold up in a court of law? I don't!). But SAS for TLS seems to be interesting to some people, as we have recently discussed on the main TLS list:
http://www.ietf.org/mail-archive/web/tls/current/msg02832.html /psa
smime.p7s
Description: S/MIME Cryptographic Signature
