[Telepathy] API sketches for encrypted channels, and OTR

[Cosimo Cecchi]

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
here.

Encryption interface:

      * 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
        errors.
      * this works a bit like InitialVideo / InitialAudio in the
        StreamedMedia interface, where EncryptionState is an immutable
        property in that fashion.

Verification interface:

      * channels of this kind pop up once an encryption request is
        fired.
      * 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
        clients.
      * 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 :-) ).

Cheers,

Cosimo