On 3/27/09 2:32 PM, Justin Karneges wrote: > 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.
The IETF is not a monolithic entity. The topic of OTR came up in my conversations with individuals who attended the IETF meeting. That doesn't mean that a specification for OTR (or OTR-NG or whatever) would be accepted by the IESG for advancement to Proposed Standard. >> 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 cc'd him on my original message and I've done so on this message. > 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. My proposed solution for offline messages is that if you know someone is offline, send this: <message> <body>Ping me when we're both online.</body> </message> That doesn't seem to be very popular. But, hey, that's what buddy pounce is for, no? Personally I would be happy with your option #2. >> 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. Right. So we're back to the tradeoffs you enumerate above. >> 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. I don't think that's quite right. All the developers hated RFC 3923 from the beginning because it was totally un-Jabber-ish (you mean I need to code up a CPIM parser, a PIDF parser, and a MIME parser?!?). > 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 do think there's some of this. > 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. Agreed. I think that XTLS is the closest we've come to something that is mostly plug-and-play for developers, because they can use their existing TLS implementation. >> 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. That's an interesting perspective. I don't think that a JavaScript client necessarily is downloaded from the same server where you connect for XMPP communications, but probably that will be the case. I suppose that you could run some kind of comparison of the downloaded JavaScript against a canonical version (does anyone do checksums for JavaScript code?), but as far as I know that kind of thing is not very common. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
