[Telepathy] API sketches for encrypted channels, and OTR

[Cosimo Cecchi]

Hi Will and Telepathy hackers,

On Mon, 2009-10-12 at 17:31 -0400, Will Thompson wrote: 
> 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
> • ...

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.

I really like the idea of Verification channels to exchange keys, and I
think one point we need to investigate is the role of certificates in
this: XEP-XTLS [1] implies we should always use X.509 certificates for
the TLS handshake; everything's fine as long as the two parties can
verify each other, so the hard point is bootstrapping a first secure
channel where you can exchange the actual certificates. This is where
TLS-SRP (Secure Remote Password) comes in handy: basically you and the
other peer agree out-of-band on a shared secret before requesting an
encrypted connection, and that secret is used to create a secure
channel. On this channel we can then securely exchange the certificates,
and use them for any further communication without resorting to SRP
anymore. My interpretation of the XTLS XEP is that we should *not* rely
on SRP for actual communication, but just use it as a mean to securely
obtain the certificates needed for communication.

Based on this, I came up with a sketch of API for Encrypted/Verification
channels. I have a lot of doubts on details, and this is the first time
I work on the specification, so please give me a lot of feedback and
forgive me if all of this doesn't make any sense at all :)

Verification
- properties: 
      * LocalCyphers (as): the cyphers supported by ourselves (X.509,
        OpenPGP, ...). The XTLS spec seems to imply that in the future
        something other than X.509 might be used for purposes different
        than end-to-end XML streams, so we should have a knob to tweak
        it. 
      * LocalSecret (s): the hash of our certificate 
      * RemoteCyphers (as): the cyphers supported by the remote contact 
      * RemoteSecret (s): the hash of the remote contact's certificate
- methods: 
      * ProvideVerification (s: Password) -> b: Success. This starts a
        TLS session secured by SRP, and exchanges certificates with the
        remote contact over that channel. It's still to be determined
        how these certificates should be retrieved and stored. After
        this has completed, the TLS session will be closed, and
        VerificationResult will be emitted again.
- signals: 
      * VerificationResult (b: Result, u: Error). Indicates the success
        of a verification operation. There will be an error for unsigned
        certificates; in that case ProvideVerification() should be
        called with the shared secret, and this signal will be emitted
        again.

The Encrypted channel should not IMO have a Verified property, as we
want to use SRP to always verify self-signed certs. So an Encrypted
channel would be automatically guaranteed to be verified.

I still have to think whether a scheme like this might work properly
also with other algorithms, like OTR.

This is all for now. During the last week, under Sjoerd's advice, I've
been hacking a dummy jingle engine inside Wocky [2] (negotiating nothing
more than raw-tcp) to move on hacking certificate validation in the
library as soon as possible. Feedback on that is welcome as well :)

[1] http://xmpp.org/extensions/inbox/jingle-xtls.html
[2]
http://git.collabora.co.uk/?p=user/cosimoc/wocky.git;a=shortlog;h=refs/heads/xtls

Cheers,

Cosimo