[Telepathy] API sketches for encrypted channels, and OTR

[Adam Schreiber]

I know that this is all going on at the telepathy level, but as one of
the seahorse maintainers, I will be filing bugs against the ui's of
clients I find exposing the status of encryption via inband text or
other methods that would be easily spoofed by a sender.  I would
appreciate it if a word of warning could be inserted into the API
documentation or implementers guidelines if any exist.

Cheers,

Adam

On Tue, Dec 29, 2009 at 9:01 AM, Cosimo Cecchi <cosimoc at gnome.org> wrote:
> 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
>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>