At IETF 74 earlier this week, I discussed end-to-end encryption with a number of people. Most of these discussions happened outside the BOF (that's how IETF meetings go). Several topics kept popping up, so I'll try to summarize them here...
1. Why Not Use OTR? Many IETFers use OTR to encrypt their IM traffic, so they wondered why we don't just use OTR. The last time I looked, I think there was only one library for OTR, so that might be a problem (also it is not fully XMPP-friendly because it was designed for cross-protocol IM only, not encryption of complete stanzas etc.). But I admit that I haven't looked at OTR in quite some time, so I'll try to review it again soon: http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html 2. Offline vs. Online Some folks didn't like the idea of XTLS because it is stream-based, not 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 doesn't address all the use cases (as he put it, it seems silly to have 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 end-to-end chat, not things like secure file transfer, since they go out of band. 3. Streaming Handshake, then Object Encryption? One possible approach we discussed was to use a TLS (or TLS-like) handshake to bootstrap trust or exchange keys, then to use object encryption after that for XMPP-native encryption. The use of TLS would then be restricted to Jingle (i.e., "this transport must be secured via TLS or DTLS before exchanging application data over the channel"). 4. Modifying RFC 3923? If we define an object encryption approach, it might be possible to modify RFC 3923 or define a 3923-like approach that removes the dependency on CPIM [RFC 3860] for messages and PIDF [RFC 3863] for presence, because that's one of the sticking points for implementation. It's also possible that we'd remove the dependency on MIME (no clients natively support MIME for XMPP traffic) and even X.509 (use bare keys, not certs). 5. JavaScript Clients 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 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 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 instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc. There's a lot to talk about here, but I at least wanted to get some of the issues out in the open. If you participated in these discussions at IETF 74, feel free to amplify or correct this report. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
