-- James A. Donald wrote: > > * The user should automagically get his > > certified key when he sets up the email account, > > without having to do anything extra. We should > > allow him the option of doing extra stuff, but > > the default should be do nothing, and the option > > to do something should
Ian G > For clarity reasons, I think you mean that the default > should be to not invoke the 'extra stuff' on automagic > creation, rather than "do nothing" I have amended the post to read, "the default should not require any input or clicking or thought from the user" http://blog.jim.com/ "How email encryption should work" > it creates a dependency on a server that might not > exist and even if a good idea, will take a while to > prove itself. On what basis then do we create the user's key? If we create it from the password alone, then his password can be dictionary attacked, so every signed post reveals his password, reducing, not increasing, his security. If we automagically create a secret key stored on his computer, then when he wanders over to another computer, his key changes, surprising both himself and those he corresponds with, resulting in mail failures. Hence my proposal that in the default case the key be created based on a PDM server's reaction to his password. If we have message signed by a key based on a secret file, we should not encrypt by default. Perhaps the default reply policy should be set in the accompanying certificate, and if no certificate, signature implies very little except message integrity and persistence of identity - "this message apparently posted from the same computer as the last message from <nickname>" Of course, this could be remedied by explicitly changing the semantics of petnames, that a petname corresponds to a particular email address on a particular computer, but that makes changes of petname too frequent, unintentional, and to end users, surprising. James A. Donald: > > * The email client learns correspondent's public > > keys by receiving signed email. Ian G > The problem I've discovered with this is that the > signing of mail is (I suggest) not a good idea unless > you have a good idea what the signature means. It means whatever the certificate asserts that it means. If the signature is accompanied by the certificate described as the default case in my proposal http://blog.jim.com/ "How email encryption should work:" it means you are receiving mail from the someone capable of receiving email at the sender's address, rather than a phisher or a virus working through someone's address book. (To conceal the infection, viruses make the "from" address anything in the address book except the actual from address.) This provides some immediate utility to the ordinary user who does not care or know anything about cryptography - ultimately resulting in signed email being privileged in spam filters. Banks will be able to send out account information in email without being blocked by spam filters, or setting up their users to be scammed by phishers, or to have their identity stolen. One minor problem with whitelists is that I have frequently been under massive spam attack by virus generated email supposedly originating from people I know. Aggressive whitelisting is going to lead, is already leading, to aggressive purloining of social network information to penetrate the whitelists. > Which means that most people under most circumstances > should not send most emails out signed. Which sort of > makes "signed emails" a poor carrier pigeon for a key > exchange. > > (I don't have a solution to this - just pointing out > what I see as a difficulty. The workaround is that > the user turns off signing and has to send an explicit > blank signed email as a key exchange message. > Clumsy.) Turning off signing by default may well be desirable, certainly desirable if one lacks a certificate that provides added value to the signature - but any key exchange is clumsy - making signed letters a key exchange mechanism that is relatively transparent to the user. We could have a mechanism whereby the user explicitly injects the public key into the email, thereby turning on the encryption default - but this requires conscious thought, understanding, and effort. I was looking for automatic encryption. It just works, so long as both clients are using the same protocol, and no one has to do anything If the user is going to send the public key explicitly, to turn on encrypted communication, then there needs to be a checkbox "Request encrypted reply" - and if you request encrypted reply, you automatically send a public key in the header, but no signature is required. The user knows that the only person who can receive his reply is the person he replies to, but does not necessarily need to connect that identity to some other label. Of course if our goal is not "encrypt everything", but rather "allow the user to encrypt some few things", then of course we just use local keys, with no certificate. If there is no certificate, then as you suggest the signature has no semantics, and should not be presented to the user as a signature, but merely as message integrity, and we warn the sender requesting an encrypted reply that the secret key to read the reply email is stored in a file in such and such a location on his computer. My goal was, however, "encrypt everything", much as paper letters about my family, my niece, and our holiday in Hawaii are routinely signed and routinely sent in envelopes. Unless we have an "encrypt everything" policy, our system is only going to provide benefits to the small minority that understand encryption, care about it, and think about it - which appears to be a few dozen, insufficient to support decent software. We need to provide benefits to the masses, without the masses needing to understand, think about it, or care. If the client fails to contact the keyserver, we could fallback from "encrypt everything using a public key based on the other guys password strengthened through PDM", to "encrypt selected messages using a public key based on the other guy's secret file". The secret file has a transient identity. Absent a (possibly self signed) certificate asserting otherwise, it is assumed to go away quickly, merely proving that the reply to one letter can only be read by the same person who sent the previous letter - providing secrecy and continuity within a particular email thread, not lasting and long lived identity, hence no petname for a key without a certificate. We don't expect the same person to hold the same uncertified key for very long, easy to make, easy to discard, hence of limited value for resisting viral spam and phishing impersonation attacks, and for securing identity information sent in email, which is the main added value we can provide for Joe sixpack. Burmese freedom fighters are a pretty limited market. James A. Donald: > > * The signature is in the mail headers, not the > > body, and signs the body, the time sent, the > > sender's address, and the intended recipient's > > address. If the email is encrypted, the > > signature can only be checked by someone who > > possesses the decryption key. Ian G > I had an entertaining read of the paper on Naive Sign > & Encrypt last night. There are a lot of issues in > how signatures are combined with encryption, I don't > think this is a solved issue by any means when it > comes to email. A google for "naive sign and encrypt" turns out rather too many hits. To what are you referring? > When cryptograpers say a message is signed, users > think that a message has been signed.... getting > around that confusion is quite hard. Ink signatures are closely associated with the person, and generally persistent for the person's lifetime. Computer signatures necessarily less so. In the default case I describe above, the signature has the semantics. "This email comes from someone who can receive email at this address, and he is using the same password as he did last time you received email from him." - which should, I think, appear literally in the certificate, or in url in the certificate referring to a resource that the email client caches. I have modified the blog post by adding a paragraph on signature semantics. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG N/KRlzRxr0kjmLO5GIu1obJohzqXYs3rUpqvyLpq 4i3AX1hCB/K8t0xa+NZPZbW4+tuAh9Q9eJBTI6UMZ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
