[Telepathy] API sketches for encrypted channels, and OTR
cosimoc at gnome.org
Tue Dec 29 06:01:02 PST 2009
On Wed, 2009-11-25 at 17:45 +0100, Cosimo Cecchi wrote:
> As you might or might not know, I'm currently working on encryption in
> Telepathy as my thesis project :)
> I've been brainstorming a bit about this proposal in the last few days,
> and I want to start a discussion about what I've thought so far.
Hi everyone again,
I had some conversations with Sjoerd about the proposal I sketched out
in my last mail.
We stepped a bit back off XTLS and SRP and made some improvements over
my proposal, and drafted out some possible spec bits and thoughts for
the Encryption and Verification interfaces, which I'll try to summarize
* this is the entry point for requesting an encrypted channel to
another contact. It should probably have a EncryptionRequest
(bool) property which indicates the will of the initiator to
start an encrypted communication.
* the main issue here is that the encryption request can't be
satisfied immediately and, even when it errors out, it will
happen after a while (i.e. after the verification steps have
been completed). So, the idea is to have another property,
EncryptionState (enum) which indicates the actual state of the
request (we could have three states here: NoEncryption /
Pending / Completed, the actual names to be decided yet). During
the pending phase, all the messages are queued until the
connection is encrypted, otherwise all the messages are sent as
* this works a bit like InitialVideo / InitialAudio in the
StreamedMedia interface, where EncryptionState is an immutable
property in that fashion.
* channels of this kind pop up once an encryption request is
* ideally we want a single verification path, which serves both
for validating login server certs and E2E XTLS certs; this
doesn't play too nicely with the XTLS spec. During your server
login phase you get the whole SSL certificate from the server,
while in XTLS there are additional handshake steps: the
initiator sends his cert fingerprint over jingle (in-band), the
responder either does the same or she picks an interactive
verification protocol, like SRP (or just decide to trust the
fingerprint). Only after the handshake, the actual SSL certs are
exchanged over the E2E link, ready to be verified.
* we thought of splitting the SSL verification into an own
transient object, e.g. SSLCertVerification, which would contain
the cert in a property. The object would have Accept() and
Reject() methods and the policy to call them would be up to the
* the other part of interactive verification is done in the
Verification channel, which takes care of setting up and
handshaking the connection up to the point we have a
certificate. For example, in case we're doing E2E security, the
SSLCertVerification object would pop up only after we told the
Verification channel our fingerprint and that we're going to
accept an SSL cert matching the fingerprint provided the other
side of the communication.
This is basically all. Feel free to contact me if something is not clear
enough (but I'm happy things are getting clearer for me since my
previous mail :-) ).
More information about the telepathy