[Telepathy] Spec meeting notes on SASL authentication and SSL cert verification

[Eitan Isaacson]

On Thu, 2010-01-21 at 11:40 +0000, Simon McVittie wrote:
> On Wed, 20 Jan 2010 at 11:39:44 -0800, Eitan Isaacson wrote:
> > On Wed, 2010-01-20 at 17:59 +0000, Will Thompson wrote:
> > > Sjoerd and Simon think we want different channel types for verifying
> > > servers' certs and for verifying contacts', with a common interface,
> > > rather like how (modern) tubes are
> [...]
> > I think I like this idea, but just to see I understand:
> > 
> > Channel.Type.CertificateVerification will have one property, "Resource".
> > The only paths that utilize this channel type are Connections.
> 
> No, something like:
> 
> Channel.Type.ServerVerification
>     readable property Server: s
>     TargetHandleType = NONE
>     requires interface Channel.Interface.CertificateVerification
> 
> Channel.Type.ContactVerification
>     TargetHandleType = CONTACT
>     requires interface Channel.Interface.CertificateVerification

Much clearer, thanks.


> Is Simon the local Telepathy user or the remote XMPP user in this diagram?
> 
> It seems you're using the same channel to authenticate Simon's identity to
> Joe, and to authenticate Joe's identity to Simon. If that's the case, then
> it's important that the spec text (and examples) make it completely clear
> who's being asked to trust what.
> 

So the gap here is just documentation? I could improve on that.

> > > So we actually just want the channel to have an
> > > array of PEM fingerprints, an Accept() method, and Reject( reason goes
> > > here? ) method, and not have separate objects for each certificate.
> > 
> > I had no idea this scenario could exist. You could identify with
> > multiple certificates simultaneously?
> 
> No reason you couldn't...
> 

I couldn't find this in any spec[1][2][3], that is why I asked.

> > Anyway, if this is really the case, I think a good way to deal with it
> > is in a linear fashion, while keeping SSLCertVerification singular. For
> > example:
> > 1. Receive CACert signed cert from peer, channel state is
> > AcceptCertificate.
> > 2. Reject certificate with 'untrusted' reason.
> > 3. StateChanged is fired.
> > 4. Receive Collabora CA signed cert.
> > 5. Reject/Accept
> > 6. goto 3
> 
> Do we really want to force prompting the user n times as a matter of API?
> 
> It seems to me that the actual question being asked is "I have these two forms
> of identity, are they sufficient for you to believe that I'm me?". If this
> is the case, then you might as well present all available certificates
> in parallel.
> 
> (There is another possible trust level: perhaps Mikhail doesn't trust either
> CAcert or Collabora individually, but is willing to believe that if both
> CAcert and Collabora say I'm me, then they're right :-)
> 
> > But apropo certificate lists, I chose to send a single PEM encoded
> > certificate, while it seems that many TLS APIs provide a list of
> > certificates that represents the signature chain. I chose not to include
> > those for the reasons below.
> 
> What are those reasons?
> 
> If the CM has the signature chain, it might as well tell the client; at worst,
> the client ignores it.
> 
> In particular, if the certification model is more complex than the CA model
> of "blindly trust a set of designated CAs to sign anything, don't trust anyone
> else at all" (think XMPP end-to-end encryption here, rather than
> authenticating servers), you might well need the whole certificate chain.
> 

Yeah, I'll add that.

> > About cert properties: We should probably add fingerprint as a property,
> > as for other properties, it may get tricky since we are not relying on a
> > specific type of certificate, so it may be an openpgp x509, or whatever
> > which have different fields(?). Although there might be a few common
> > ones, didn't actually look at this.
> 
> Why can't the UI just receive all the "source information" the CM has, and
> make its decision based on that? (For instance, if the UI wants to show the
> user a fingerprint, it can compute it from the cert.)
> 

That is currently what's expected. The client receives a raw PEM it
could parse any way it wishes.

> > > We want to avoid clients relying on the CMs doing preliminary
> > > verification on certs, so maybe Certificate_Status should go away.
> > > (Sjœrd may already have said this in an email.) A CM should present
> > > certs without comment, and the client should say yes, no or meh; only in
> > > the meh (legacy) case should the CM make its own judgements.
> > 
> > This makes the most straightforward use-case a bit more complex -
> > present the user with a dialog when verification fails, and let them
> > decide to ignore the failure.
> 
> I'm not convinced that "Here is a popup you do not understand because it's
> full of scary words like SSL, certificate and fingerprint. Do you want to keep
> talking to someone who looks superficially like your friend Joe?" is good
> UI to be treating as a baseline in any case - everyone will just click "yes"
> and carry on with their unencrypted lives :-)

It is a wonderful way of life :)

I misunderstood the basic aim of this API. I thought we were mostly
making it easy for clients to deal with verification exceptions, not
move verification entirely to the client. With that in mind, a lot of
your points make more sense.

> 
> > In the current draft, the client just needs to read the
> > CertificateStatus property, and present a human readable notification to
> > the user with accept/reject buttons.
> 
> How do you produce a human-readable notification without understanding the
> certificate?
> 
>     This certificate is issued to a name that differs from the name we
>     want. I'm not actually going to tell you either of those names or
>     let you look at the contents of the certificate, so even if you're
>     a cryptographic ninja, you can't make an informed decision. Do you want
>     to continue?
>     
>                                     [ Connect anyway ] [ Cancel ]
> 
> :-)

If Empathy and friends will ever join the family of networked
applications, they need vague, arse-covering, security dialogs :)

> 
> > If the property goes away, the client will be forced to utilize a TLS
> > library to do it's own verification magic.
> 
> I don't think requiring a UI for TLS certificate verification to use a TLS
> library is necessarily very onerous :-)
> 

The reason I was hesitant is mostly because it dictates a substantial
amount of duplicated effort where the CM and UI both implement similar
verification. There seems to be effort put in on a few levels to
abstract TLS libraries, Wocky has both an openssl and a gnutls path, and
gio will be library agnostic as well. If the UI will use a TLS library
directly, it seems like it would defeat the purpose. It will need to
abstract the TLS functions as well, which is another headache.

Not saying they shouldn't, but I didn't think they should be required in
order to use this API.

In any case, I understand now that this API will ultimately transition
verification to the UI, so there really is no way of avoiding having the
UI do TLS ops.

> > Also, how certain is the client of the remote server's hostname? It
> > seems like there is no definitive way of knowing, there is only a
> > well-known RequestConnection 'server' parameter, maybe I missed it? In
> > the XMPP case, a CM might do some additional DNS voodoo, like SRV and
> > reverse lookup, a protocol-agnostic client won't be able to reliably do
> > this.
> 
> Yes, the CM needs to tell the UI what server name the UI should be verifying
> (e.g. via the Server property on the channel).
> 
> In some protocols we might need to give the UI a list of hostnames any of
> which would be acceptable, I suppose?

That is a good idea!

Back to work,
  Eitan.

1. http://tools.ietf.org/html/rfc5246
2. http://tools.ietf.org/html/rfc5081
3.
http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html



-------------- 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/20100121/77abb785/attachment.pgp