[Telepathy] API sketches for encrypted channels, and OTR

Tue Jan 5 10:00:40 PST 2010

On Tue, 2010-01-05 at 14:55 +0000, Sjoerd Simons wrote: 
> 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

Right. I see more API additions for E2E functionality. Somewhere along
the line, after a client (from either end) has initiated E2E and
requested certificates as the authentication method, than a channel of
the type below should come through. It's the same pattern with the
Connection, we request the connection be SSL secured, and during the
'connecting' stage we receive this channel.

> 
> > org.freedesktop.Telepathy.Channel.Type.Verification
> > ===================================================

Maybe this should be called CertificateVerification so it is less
ambiguous?

> > 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...)
> 

Dang, that's a bit less elegant than I hoped for. Would the target
channels always preexist? The way I saw it, the tube/text channel would
only be created after the mutual authentication and crypto negotiation.
That way there are no questions regarding the channel's security. But I
guess what you are saying is that there would be some flag on current
channels signifying their encryption state?

I only found daf's notes after I sent this out, where he suggests the
same thing. I guess another property called Resource would contain the
object path of the target channel/connection.

> > 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...)

Perhaps another property called RequestedIdentity:s that would store
which identity the remote end is expecting?

> 
> > 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

I guess I was thinking of another use-case without even realizing it. I
was thinking that besides the "leap of faith" interaction that this API
provides, it also allows the client to add additional scrutiny to the
verification. For example, test against an extended revocation list, or
only trust a subset of the standard CAs. In this case, the client would
reject the certificate without user interaction, and should give a
reason why it was rejected, so the user sees that when the connection
fails.

Originally I had this as a Reject() argument, but I ended up thinking it
will complicate what is supposed to be a really simple method. Instead,
since this is essentially an override, it looked more correct to have
the client modify the channel property itself, if it wished to
scrutinize the authorization and reject the certificate on it's own
terms.

> 
> > 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.

Are you sure you mean CMs? It sounds like you mean clients. CMs are
doing the verification currently. And they have much more authority for
detecting hostname mismatches since they actually deal with the sockets.

My proposal is for accommodating the use-case above. The CM is
responsible for doing a full verification, but the client may further
amend it, like I mentioned above. If you think this is a horrible idea,
I would propose leaving verification on the CM altogether, and only
expose this API for the "leap of faith" purpose.

> 
> 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.

Yeah, that is how I imagined it too.

Cheers,
Eitan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20100105/68b9da6a/attachment.pgp 