Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Fri, 12 Sep 2003 20:12:13 EDT, Sergey Babkin said:
Many ISPs (and IT departments) already require the users to enter
a password to send e-mail. So the mail server knows reasonably
well who the sender is. What it can do now is write this user
information into the e-mail's headers, then calculate the checksum
of the whole message and sign it with the mail server's key
(and possibly do the same thing for the identity-relation portion
of the header). When the addressee receives the e-mail, he can
look up the server's private key and check the signatures, to make
sure that the sender is who he claims he is.
There's a good reason not to do this - what you're really signing may not be
what you thought. If the server is signing the mail with its own key, what
you've established is the statement "The mail server said
fred(_at_)foo(_dot_)com sent it".
Exactly.
Notice we haven't actually proven that fred did anything - we've proven the
(effectively) hearsay assertion by the mail server".
Yes. But it's good enough for most practical situations (those
not involving courts and high security clearances).
Now let's think about this - what if the server is *lying* to us? There's
Just take this signature as an advisory, not a proof. This mode
is good enough for most situations.
several threat models here:
1) If the server is compromised, you basically just lost *all* confidence in
all the signatures. The reason that things like smart cards are attractive is
Same thing as if a multi-user host with the users' keys on it
is compromized.
2) I set up a rogue mailserver at mail.foo.com. I send a forged mail with a
bogus From:, and sign "yes, this mail is From: bogus(_at_)nowhere(_dot_)com".
You then
look up my mailserver's key and check, and trust the claim. What's wrong
here?
Basically, you've equated "A mail server just said what it sent was the truth"
with "it actually is the truth".
You can still trace the origin of the message to the creator of
the record mail.foo.com.
You could probably create a variant where you only trust the mail server's
assertion if its key was itself signed by a third party with an endorsement of
No, I think that this approach is useless, because it pretty much
returns the situation to how it is now. Registering the keys
would become difficult, plus there is always the question of
how the third party knows that it's signing what it thinks it's
signing.
the form "This mail server is in fact allowed to assert the source of mail for
the foo.com domain only", and then only trust it if it's foo.com mail, and not
nowhere.com mail.
You can do it without all this infrastructure - just compare the
domain name of the key and the domain from which the e-mail has
allegedly originated. If they don't match, refuse to accept the e-mail.
I'd hate to deal with any mail to/from an e-mail outsourcer like psmtp.com
however. Their certs will be *huge* - I think they provide service for well
over 100K domains. So I'd have to either fetch a multi-megabyte cert to verify
a 2K mail, or I need a caching system for certs. There's little to no joy in
that, especially since we're trying to fix a broken model in the first
place...
I think that storing the keys in DNS eliminates the need in such
certificates. Well, if you want something really secure, you would
still need the certificates, but for many practical purposes
the spoof-resistance of DNS is good enough.
A much better model would be finding a way to easily/painlessly push the
cert management back to the MUA where it belongs.
Well, if we look at rsh/ssh, I find that dealing with distribution
of the keys for ssh (especially that I have multiple keys
for different purposes - some for work, some for personal
use etc.) requires more effort than remembering passwords.
Tha same thing would be true for MUAs as well, and even worse.
-SB