[Telepathy] API sketches for encrypted channels, and OTR

[Will Thompson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20091012/1f38e1eb/attachment.pgp