On Friday 27 March 2009 11:56:27 Peter Saint-Andre wrote: > 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
Funny, I'd have thought OTR wouldn't be IETF-friendly. The same critiques that apply to Esessions apply to OTR. > 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. [I don't see Pete CC'd?] I'd like offline message encryption also, but then replay protection and forward secrecy may become impractical. The options seem to be: 1) Don't have offline encryption. 2) Have offline encryption with lesser security. 3) Reduce security of online encryption so that online and offline are equivalent. I pick #2. Yeah, maybe it's goofy to use different approaches for online and offline, but unless you pick #3, there's going to be different security levels anyway. > 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"). Object encryption is nice, but probably not at the cost of being unable to use TLS as-is. We can have object encryption for offline messages I suppose, since we probably wouldn't use TLS for that. > 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). I agree we don't need CPIM/PIDF or MIME. But CMS is the coolest thing ever. That said, I think the main reasons RFC 3923 is not implemented in clients are: 1) XSF simultaneously promoting ESessions/XTLS with better security (due to being stream-based), which is super confusing to developers and it makes it seem like the XEPs supercede the RFC. 2) Simple lack of time or interest in end-to-end encryption in general (nobody expects the dominant clients to implement any of this e2e stuff, right?). I guess if we could use TLS to bootstrap a session of CMS object encryptions that would be sweet. But let's be serious here, the more we deviate from the norm, the harder it becomes to have our proposal taken seriously and be implemented. > 5. JavaScript Clients I know the world is all web based now, but I draw the line here for e2e encryption. Maybe somebody can explain to me again how e2e encryption at the client side is all that useful when the client code itself is downloaded on-demand from the server you'll be sending IMs through anyway. May as well have the server do the e2e work. -Justin
