Hi, Here at the Boston Gnome Summit, Sjoerd, Rob and I stood around a blackboard drawing pictures[0] of how encrypted channels (using XTLS on XMPP, for instance) would look. Vague summary:
Connection has Verification channels (because they could be dispatched to a verification UI) which let you do key exchange with various contacts. Verification channels point to the set of channels they relate to (mutable). Verification: • Cyphers: as • ... Encrypted channels (text, FT, call, tube, ...) have an Encryption interface: • Encrypted: b • Verified: b • VerificationObject: o Properties can only move from False to True within the lifetime of a channel. Maybe we should make Encrypted immutable instead? CM can opportunistically encrypt; you don't need to have a Verification channel handler *or* a UI which understands them. But if you want you can request a channel with Encrypted: True, Verified: True, and then presumably the channel request would wait on the Verification channel being acted upon appropriately. (If the Verification channel was closed without being sorted out, because it couldn't be dispatched, then your channel request would fail). Connection may need a KeyManagement interface; resolved later. (Side point: we could make SASL be a channel too, which is dispatched while the connection is still Connecting. This would mean that MC would dispatch the Kerberos challenge or whatever.) We then discussed various ways we could implement OTR support in Telepathy, ideally using the same API as for XTLS channels: 1. Build OTR support into the necessary CMs (Gabble, Butterfly, Haze) and implement the same API as for XTLS. Pros: • UIs which support proper encryption can do OTR without modification Cons: • Have to link libotr to all those CMs, which feels like a duplication of the same code. 2. Have a proxy CM which pretends to be gabble etc. and runs the real CMs on a private bus, proxying all their channels verbatim except for those which it frobs for OTR. Pros: • UIs which support proper encryption can do OTR without modification. • Only have to write it once. Cons: • Yet another tiny daemon; • Has to pretend to be all the CMs before MC5 starts; • Easy to mess up, hard to debug, confusing. 3. Write an observer which also pretends to be a CM, which pops up OTR-proxied text channels (implementing the standard encryption API) when it sees the OTR message fly past. Pros: • Don't need to modify CMs; • Only implement OTR once. Cons: • Need to modify the UIs to understand magic sidecar channels, which would need an interface saying "I'm like that channel over there -->"; • Unmodified loggers get misc base64 in their logs. 4. Put OTR support directly into all the loggers and UIs Pros: • Don't need to modify the CMs; • Don't need yet another tiny daemon, with weird sidecar channels. Cons: • Need to modify the UIs even more severely, linking libotr into every one; • Unmodified UIs and loggers get base64. Sjoerd and Will prefer 1 (Will likes the idea of 2 in principle because it keeps the OTR in one self-contained blob, but thinks that in practice 1 is easier to implement and maintain); Rob prefers 2 or 3. Note that we can't just use the standard Pidgin plugin in Haze because it uses the dialog box API and writes crap into the conversation window, but the code would be very similar to that in Gabble (unless the code is in Wocky, which Sjoerd is pro-). So option 1 would involve 2½–3 implementations of OTR support. It's not really worth implementing it for the other CMs (OTR on IRC/SMS/SIP? Woo). [0] http://people.collabora.co.uk/~wjt/tmp/encrypted-channels.jpg Regards, -- Will
signature.asc
Description: OpenPGP digital signature
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
