[Telepathy] Designing Telepathy/XMPP end-to-end security

[Simon McVittie]

By "the payload channel" I mean the Chan.T.FileTransfer, Chan.T.Call1,
Chan.T.StreamTube or Chan.T.DBusTube whose contents are protected.

On 12/06/12 14:42, Simon McVittie wrote:
> * Optionally (open design question: do we need this?), Alice's
>   connection manager could pop up a Requested=FALSE channel
>   representing the request "give me the certificate you want
>   me to use"

If needed, this can't be an interface on the payload channel: it has to
be a separate channel, a requestable property, or not offered at all.

Rationale: if it was an interface on the payload channel, a legacy
Handler (not supporting e2e) would never answer the question. The CM
would have no way to know that the question would never be answered, so
it would wait forever, and be unable to send session-initiate.

Perhaps we don't need this: telepathy-gabble could generate a
self-signed certificate per JID and use it unconditionally. In practice,
nobody has a CA-signed XMPP client certificate anyway.

The other thing we need before sending the Jingle session-initiate is to
know whether we should offer Bob SRP (secure remote password). If Alice
and Bob have pre-agreed a username/password, we want to offer SRP, by
sending Alice's username when TLS commences; if they haven't, we don't;
and ideally we don't want sending someone a file to always produce an
interactive "do you have a SRP username/password? If so, what's your
username?" prompt. Perhaps we should make the SRP username a requestable
property of the channel, and not offer SRP without it?

RFC 5054 describes a mechanism for advertising that you support SRP
without providing your username, but it requires reconnecting. I'm not
sure that we really want to start a new Jingle session for this...

> * Optionally (open design question: do we need this?), Bob's
>   CM could pop up a channel representing the request "give me
>   the cert you want me to use"

Similarly, this can't be an interface on the payload channel. There is
no request here, so a requestable property is not possible either. It
has to either be a separate channel, or not offered at all.

> * If Alice has requested protection from active (man-in-the-middle)
>   attacks, i.e. Conn.I.Securable.Verified=TRUE, then her CM pops
>   up a channel analogous to the current Chan.T.ServerTLSConnection,
>   representing the question "do you trust that this is actually Bob?".

This can't be an interface on the payload channel either.

Rationale: during file transfers where Alice sends a file, Alice
initiates the channel and Bob responds. We don't want to send the actual
file until Alice has had a chance to either say "yes this is definitely
Bob" or "I don't care, use a leap of faith". At the same time, we want
it to happen (or, in this case, fail) in a finite time if unhandled.

> * Because Alice might be planning to authenticate Bob informally
>   by recognising his voice, the verification channel probably
>   needs a method with the semantics "not verified, but let
>   application data flow anyway, and I'll make up my mind
>   later".

I think there are four possible results, although maybe the CM doesn't
need to know the difference between the last two, or even the last three:

* consider to be unverified and abort
* consider to be unverified, but proceed with caution
* take a leap of faith, trust that this is really Bob, and store
  the key for the future (like ssh)
* positively identify the peer as Bob and store the key for the future

Unless we require/expect users to carry out elaborate key management, we
can't assume that a changed cert is *necessarily* bad, either. If I talk
to you from my laptop and then from my phone, it's entirely reasonable
that they have different keys - so the UI can't scream about it as much
as SSH does, and it would not be reasonable for the CM to reject the
call from my phone unilaterally.

The XTLS draft suggests using XTLS for XML streams, which gives you the
ability to do secure key exchange once the XML stream is up (so, in
principle, my laptop could tell you "here is the cert from my phone,
which is also genuine"). That would require manual key management,
though (I'd have to tell Empathy on my laptop about the cert I planned
to use on my phone).

> * If Bob has configured his CM to always request protection from
>   active attacks (design question: should this option exist?),
>   he gets a similar verification channel.

If supported, I think this should be a channel (not an interface on the
payload channel), for similar reasons. It doesn't necessarily matter for
receiving a file, but is significant for Tubes or "reverse file
transfer" (requesting a particular file from a peer, which XEP-0234
supports).

The use of separate channels is good if you're doing all the
cert/key/trust management in a separate application (like the way the
Empathy.Auth sub-app handles ServerTLSConnection channels), but not so
good if you want to integrate the authentication step into the same UI
as the payload channel. I'm not sure how best to deal with that.

I think we probably want to guarantee that the payload channel appears
first (even though it won't be usable until the TLS and Jingle
handshakes have completed), so that the authentication channel can point
to it, the UI for the payload channel will already be active, and we can
put together some way to tell Mission Control that you want to handle
channels fitting a particular description (auth channels in this case)
if and only if they point to a channel that you will also be handling.

We can't do the "only if related" thing by just adding a channel filter
per payload channel, because there are awkward race conditions (MC might
process the new filter after it has already dispatched the related
channel); it'll have to be some sort of secondary set of filters, or
possibly just a second Handler head with OnlyIfRelated=TRUE (where
"related" means "points to a channel being handled by the same unique
name" or something).

(We don't necessarily need to design or implement the "integrate
authentication into payload's UI" part immediately, as long as we're
confident that we haven't painted ourselves into a corner by making it
impossible to implement.)

    S