[Security] About the Firefox 3 Security Dialog & others

[Dave Cridland]

On Fri Aug 22 16:22:54 2008, Jonathan Schleifer wrote:
> If we have a CA, we need to warn for self-signed certs. But if we  
> do  it like Firefox 3 - which some here considered the right way -  
> it will  scare users away - they can't talk or won't use crypto at  
> all.
> 
> 
Fair comment - but that's assuming we have One True CA, which, in  
practical terms, is very unlikely. Even within the Internet At Large,  
where we have xmpp.net to give us free certificates, I don't think  
users will want to bother with getting certificates signed the  
majority of the time.

So CA-signed certificates would be the exception, and not the norm -  
and planning for this reality will hopefully mean we don't fall into  
S/MIME insanity.


> Another problem is that a CA means a single point of failure. If  
> that  CA is broken, someone can forge everyone.

Well, you do have to go some to completely subvert a CA. Assuming  
that someone managed it, then I imagine there'd be a few security  
updates going out, in quite a bit of noise, and to do it in a way  
that the CA themselves didn't notice would be impressive.

>  Plus I don't trust CAs  generally.

I can go along with this. That Peter chap who runs the xmpp.net one  
seems a bit dodgy.

Seriously, though, X.509 PKI is used in-house in a lot of places, so  
trusting the CA is a pretty reasonable thing to do in those cases.

With the big corporate CAs, there is so much cash at stake, an error  
would be a disaster, so if the basis for your mistrust is that their  
money-grabbing evil corporates, that's probably true, but plays into  
your hands in this case.

> So what's left?
> 
> * Self-signed keys
> * GPG
> * SRP
> 
> The problem with self-signed keys is that the fingerprint you need  
> to  verify is very long and most users just won't verify it.
> 
> 
That's okay - fingerprint verification is just one option. You could  
also - in parallel, in fact - do a number of alternate verification  
methods, some of which could look very, very like the SAS used in  
ESessions. 
Actually, I suspect we'll see mostly leap-of-faith and CA. Asking  
around Isode - and we're arguably a security-aware bunch of people -  
it turns out we've all relied on leap-of-faith for the SSH key to our  
primary firewall.

So whatever we do, we absolutely must ensure that client developers  
are doing good leap-of-faith. (And if you do that, other verification  
methods can take advantage of it).


> The problem with GPG is that this is geeks-only.
> 
> 
Oh, if you do the whole Web Of Trust thing, it's really geeky. But if  
you do leap-of-faith or SAS-a-like with it, it works equivalently to  
the above - Simon was already suggesting this, actually, although Ekr  
suggested some improvements.

FWIW, I suspect some geeky users will want to reuse their existing  
PGP keys, but they'll be in a small minority.


> The problem with SRP is bots.
> 
> 
I'm not convinced about SRP, for a number of reasons, not least that  
SRP has seen vanishingly small deployment compared to the other two  
methods, and it doesn't leverage any existing infrastructure.

> So, I think we shouldn't concentrate on one of these. We should  
> have  more than 1 way. For example, if we have SRP and self-signed  
> certs,  we'd be fine. For bots, we could also add a CA so bots of  
> the same  owner trust each other by just having the root cert.

Well, what makes sense to me is to have X.509 and GPG/PGP. I'd lean  
toward X.509 as MTI, and GPGPGP as a strongly-worded-MAY. Both these  
are supported within TLS, as I udnerstand things (which is, of course  
waaaay less than some here).

I'm assuming that during TLS handshaking, both sides can agree on  
which of X.509 or OpenPGP to use, but I don't know if this could be  
heterogeneous - I'd guess not, which would mean that you'd always  
need to have an X.509 certificate to hand, but you might want to use  
a OpenPGP key as well.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade