Valdis.Kletnieks@vt.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@foo.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@nowhere.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