Re: [Security] XMPP encryption summary from IETF 74

[Jonathan Schleifer]

Am 27.03.2009 um 19:56 schrieb Peter Saint-Andre:

2. Offline vs. Online


message-based. In particular, Pete Resnick [cc'd here because he's not
on the list] noted that XTLS can't handle offline messages and so

one technology for encrypted communication when the other party is
online and a different technology for encrypted communication when the
other party is offline). Note that this objection applies only to

of band.

Some folks didn't like the idea of XTLS because it is stream-based, not doesn't address all the use cases (as he put it, it seems silly to have end-to-end chat, not things like secure file transfer, since they go out

Wasn't this possible using ESessions? ESessions were message based as well.

5. JavaScript Clients


something significantly simpler than XTLS or RFC 3923 or OTR, we would
make it possible for JavaScript clients to play in this space. These
considerations might lead us to favor something like (1) bare keys

instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc.

More and more XMPP clients are being written in JavaScript. But there is no SSL/TLS stack for JavaScript. Furthermore, the dependency on X. 509 is problematic because there is no ASN.1 support in JavaScript, either. (I also note that there is no OTR library for JavaScript.) If we can define instead of self-signed X.509 certs [your key could in turn be signed by your X.509 cert or OpenPGP key if you have one], (2) TLS-like handshake

Shouldn't this be possible with ESessions?



--
Jonathan

Anyway, I'm fine with either, be it ESessions or XTLS. But we need to get it done. And we need to do that ASASP! In fact, it already should be done and in use! We _NEED_ end-to-end-encryption, no matter which one!

PGP.sig
Description: Signierter Teil der Nachricht