Julien Pierre wrote:
Thus, for individual users' self-signed certs to work, everybody would
need to blindly trust everybody else's individual cert. I don't see how
you expect that to actually be workable.
I'd just consider it a step better than unprotected
email. It's what you get for free, you get what you
paid for. I know that my kid sister ain't gonna be
listening any more and the next door neighbours won't
be scanning for gossip either. Later on when it
becomes important, I guess I'll need to upgrade the
cert.
(Marketing wise, CAs love this, or should. It gives
them clear clues as to where to sell.)
In email, you and I know each other and we
don't need any CA to tell us that.
That's what you may think ! Emails travel through a myriad of servers,
routers, in a non-realtime fashion, and are very susceptible to attacks
such as interception. An MITM attack that may be relatively difficult to
achieve with real-time SSL is much easier to do with e-mail.
Ever seen any? Ever heard of any? I know of
one MITM attack on an unencrypted person where
one would think that crypto might have made a
difference. That's one victim in about 15
years of the net... I'm sure there are more,
but there aren't enough to make a meaningful
statistical model. Which means it isn't much
of a threat.
I know they are possible, I know they aren't hard,
but they don't happen. They are not really a
threat to users. Unless they happen.
Later on, as an option,
we may very well want to go to the CA and
ask for "a third opinion" just like one might
go to the doctor and ask for a "second opinion"
if one is diagnosed as due to kick the bucket
tomorrow. But this should be strictly optional,
the email application should be built on self-
signed certs as a primary principle.
Using your analogy, I conclude that when you go see a doctor the first
time, you don't want to know whether he is licensed.
As it happens, the last doctor I went to was run
out of his country for some drunken surgery accident.
He's quite a character, instead of giving a prescription
he took a handful of pills out of this huge jar and
gave me those. Worked fine, he's an honest doctor,
and his reputation around the community was quite
reasonable.
But, yes, analogies can suck quite quickly :)
Anyway, it's a terrible analogy. With e-mail, there is nothing that
proves your prior relationship, as there is with a physical meeting with
your doctor.
E-mail accounts get hacked into all the time. Unless you verify identity
externally, an e-mail address by itself is not sufficient to establish
trust. You could read your self-signed certs' fingerprints to each other
over the phone before trusting them, and that would be secure . But a CA
is a a much more practical, generic, and scalable, way to go.
I think you are mistaking my intention. I do not
intend this suggestion to indicate to users that
they are really benefiting in *identity* terms,
only in encryption terms... Frankly, the business
of reading finger prints is like the business of
SSH users checking keys (even though some people
say "check the server key" I don't even know how
to do that ... and I use SSH all the time and have
for many many years). Same in the PGP world, most
people just encrypt, encrypt, encrypt.
I wouldn't object to self-signed certs if the UI to trust a self-signed
cert you just received (either via SSL or S/MIME) required you to type
in the fingerprints in the cert you expected, without the ability to see
anything in the actual cert but its DNSname or email address. Trust
would be added only if there was a match. I suspect most people would
not be able to confirm the fingerprints, and thus would not blindly
trust any self-signed certs they received . They would then figure out
it's better to use CAs after all.
Yes, show the finger prints, and offer a choice
to select a match or a petname. And show a red
pen or key instead of a blue one or something when
an email comes in. No big deal.
Right, so send an email with the key. Just don't
force it to be a signed email, or don't hide the
key exchange such that users are encouraged to
"turn on siging" so as to get the key exchange.
You can send an unsigned e-mail with a copy of the cert as an
attachment, but I don't think mozilla will process those messages. This
bug has been on my plate for years and none of my management over the
years at Netscape/AOL/Sun has ever found it important enough, so it's
still in my queue at https://bugzilla.mozilla.org/show_bug.cgi?id=36246
. It doesn't look like any mozilla S/MIME user has ever cared, either !
But if you want to fix it, be my guest. I have 35 bugs assigned at this
time, and the number never seems to go down - unfortunately, whenever I
fix one bug, I invariably uncover 2 or 3 other previously unknown bugs ...
:-) I wouldn't know where to start. Getting into
something like these systems would take a least a
month of hacking, and I'm currently drowning in my
own project ... But having worked on lots of
security systems I can see why some fail and why
some succeed, and the actual crypto is generally
not the reasons, positive or negative. There's
nothing intrinsically strong or weak about any
of the crypto stuff, it's how you use it that
matters.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
