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

[Simon McVittie]

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

> Channel.Interface.CertificateVerification is where the rest of the API
> will reside

Yes.

> > SendCertificate seems unexpected. What does the cert represent? What
> > does RequestedIdentity *mean*? Need examples.
> 
> The RequestedIdentity is the identity the remote peer needs to verify,
> for example:
> Simon is exchanging certificates with Joe. Joe has two certificates, one
> for his gmail address, and one for his work address. Since Simon is
> chatting with Joe through Joe's work account, he needs to verify Joe's
> work identity, thus RequestedIdentity, on Joe's end with show
> 'joe.plumber at work.com'. So his client knows to send the work cert.
> 
> Did I get this all wrong? Is that scenario unrealistic?

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

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

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

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

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

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