[Bug 29904] New: Support end-to-end encryption and authentication

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29904

           Summary: Support end-to-end encryption and authentication
           Product: Telepathy
           Version: git master
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-spec
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: cosimoc at gnome.org
         QAContact: telepathy-bugs at lists.freedesktop.org


Hi,

crypto-headaches are back again for everyone, now that I started working again
on a proposal to integrate end-to-end security in Telepathy ;-P

An HTML version of my new spec draft can be found here [1], while the git
branch for it is here [2].

--------
Overview
--------

The main ideas behind the design of this API are the following:
- clients should not deal with more than one additional channel to obtain a
secure end-to-end channel.
- clients should be able to choose the encryption protocol used, if more than
one are available (e.g. both OTR and XTLS could be available on an XMPP
account).
- the handling of the additional channel can be done in a separate process,
without forcing the requesting client to care about the encryption steps.
- clients which do not request encrypted channels can work without
modifications.

To accomplish that, I added basically three fundamental types to the
specification: the Encryptable interface, the ClientAuthentication channel
type, and the Authentication.Proposal transient object. On top of them I also
drafted some protocol-specific implementations.

--------------------
Ch.Iface.Encryptable
--------------------

This is the main entry point for requesting an encrypted channel, by specifying
EncryptionRequired = TRUE in the request.

The EncryptionInterface is used to specify the protocol to be used for
encryption (e.g. OTR vs. XTLS), and defines the interface supported by the
ClientAuthentication channel that will be dispatched to authenticate the
encryption process.

I thought this being a requestable property here could also play nice with the
fact that a CM could advertise the possible protocols in
RequestableChannelClasses.

----------------------------
Ch.Type.ClientAuthentication
----------------------------

It's the channel that will be dispatched to authenticate the encryption
process. The base object also keeps track of the channels around that use this
authentication, by using the TargetChannels property.

Channel.Interface.XTLSAuthentication is an XTLS interface for this kind of
channel, and one might also write Channel.Interface.OTRAuthentication on the
same line.

-------------
Auth.Proposal
-------------

It's a transient object that can be used to complete the authentication step.
Each proposal implements one interface, which defines the protocol-specific
methods to accept it.

How exactly the proposal objects are used and constructed is up to the
interface of the ClientAuthentication channel.

I drafted implementation for Auth.Proposal.X509 and Auth.Proposal.SRP, to be
used with the XTLSAuthentication interface.

There's a last object, which is Ch.Type.ClientTLSConnection, which is a way to
exchange TLS certificates between clients; this is usually needed after SRP,
and a channel of this kind would use the same Encryptable/ClientAuthentication
process described before to signal that the exchange is linked to a previously
authenticated session.

That's it for now, feedback welcome.

[1] http://people.collabora.co.uk/~cosimoc/e2e-encryption-spec/
[2]
http://git.collabora.co.uk/?p=user/cosimoc/telepathy-spec.git;a=shortlog;h=refs/heads/e2e-encryption

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.