[Telepathy] API sketches for encrypted channels, and OTR

[Sjoerd Simons]

On Mon, Jan 04, 2010 at 02:51:59PM -0800, Eitan Isaacson wrote:
> Hello!
> 
> I have been thinking about how we could best expose SSL verification
> over Telepathy to allow client interactivity. Cosimo's proposal is a
> good preliminary sketch of what it would look like, I hope to expand on
> it below, and ultimately land something in the spec.
> 
> I see client interaction in two main cases:
> 1. Accepting/rejecting a given certificate from a server or E2E session.
> 2. Providing a certificate for an E2E session.
> 
> I think it would be nice if the API was simple, and would not require
> clients to deal with server verification if they didn't wish to (ie.
> verification would stay non-interactive on the CM). Since we are only
> really dealing with certificate exchanges, I think it is best to hide
> all other handshake details and such in the CM, and only notify the
> client when we are ready to accept or send a certificate.

In the E2E case there needs to be some way to say how to verify the other side
(of which one option is certifications), but in general yeah, the clients
shouldn't care about handshakes

> org.freedesktop.Telepathy.Channel.Type.Verification
> ===================================================
> This is an anonymous channel when dealing with server verification. It
> would have a contact handle (or list id?), when dealing with E2E
> sessions.

There might be multiple E2E streams to one contact, so you don't want to key
them by contact. Channels they relate to is a much more interesting bit of
information (As in, this verification is for that text channel over there or
for that tube channel or...)

> If the channel is closed at any pre-verified state, the behavior returns
> to the legacy non-interactive CM verification. When a ChannelDispatcher
> is arbitrating, and no known handlers exist, it will close this channel,
> and thus current clients would function properly.

Sounds good.

> Methods
> -------
> GetCertificate (): This would return a
> org.freedesktop.Telepathy.SSLCertVerification object if it is available.
> Will return a null object path if not.
> 
> SendCertificate (s: Cert): This method takes a PEM encoded certificate
> for E2E verification.

There needs to be some information about what kind of certificates (if
specified) the other side needs and for which idententy. (As in do they want
the certificate for sjoerd at luon.net or sjoerd.simons at collabora...)

> Are there cases where a server would require a
> client certificate? This would be useful for that too.

One can use client certificates as authentication, so i guess in that case.

> Properties
> ----------
> State: Verification_State(u): Indicates what stage of the verification
> we are in.
> 
> Signals
> -------
> StateChanged (u: State): The state of the channel has changed, a good
> path for accepting a remote certificate or sending one.
> 
> Types
> -----
> Verification_State: 
> 	(0) None: Awaiting remote certificate or response.
> 	(1) AcceptCertificate: Waiting for client to accept remote certificate.
> 	(2) CertificateRequested: Waiting for client to send client
> certificate.
> 	(3) Verified: Verification is complete.
> 	(4) Failed: Failed to verify.
> 
> org.freedesktop.Telepathy.SSLCertVerification
> =============================================
> This type contains certificate information as well as methods for
> accepting/rejecting the given certificate. Typically a client could use
> these objects for creating and storing certificate exceptions, for
> example, accepting a self-signed certificate and storing it for future
> sessions.
> 
> Methods
> -------
> Accept (): Self explanatory, accept the certificate.
> Reject (): Reject the certificate. If this is a server certificate We
> will subsequently get a StatusChanged signal from the Connection with
> the a status of Disconnected, and a proper Cert_* reason.
> 
> Properties
> ----------
> Status: u(Certificate_Status): This property is pre-populated with a
> status that the CM provides. The CM is responsible for a preliminary
> verification using such standard CAs such
> as /etc/ssl/certs/ca-certificates.crt and
> $XDG_CONFIG_HOME/telepathy/certs. This property is writable and can be
> changed to any status the client deems. If a certificate is rejected,
> this property is used as the reason.

Using a property as the rejection reason seems awkward. Why not just have a
reason argument in the reject function? There also doesn't seem to be any
reason for setting this property yourself

> Certificate: s: This is the full PEM encoded certificate.
> 
> Types
> -----
> Certificate_Status:
> 	(0) None
> 	(1) Untrusted
> 	(2) Expired
> 	(3) Not_Activated
> 	(4) Hostname_Mismatch
> 	(5) Self_Signed
> 	(6) Revoked
> 	(7) Insecure_Algorithm
> 	(8) Other

I'm wary of requiring CMs to do some parts of the certificate verification, I'm
inclined to say that the verifier should do it completely. Especially i'm
worried of CM's failing to implement certain checks (e.g. hostname mismatch),
which would mean to be optimally security you want to recheck everything
yourself anyway.

We also need to define what the login flow will be, i guess in the CONNECTING
connection state a verification channel can popup, which needs to be handled
before connecting moves on etc.

  Sjoerd
-- 
Ask five economists and you'll get five different explanations (six if
one went to Harvard).
		-- Edgar R. Fiedler