Re: how email encryption should work (and how to get it used...)
-- On 30 Mar 2005 at 13:00, Amir Herzberg wrote: A missing element is motivation for getting something like this deployed... I think spam could offer such motivation; and, I strongly believe that a cryptographic protocol to penalize spammers could be one of the most important tools against spam. The cure for spam is not a provable link to a true name, but a provable link to a domain name. The problem with adoption is that this is only beneficial against spam if widely used. We face the usual critical mass problem. The proposal on my blog (blog.jim.com) focusses on encryption at the individual level - one key per email address, not one key per domain name. which would solve the spam problem, but is less immediately helpful than one key per domain name. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Fl8/gx81XkbuiLaqs0tMz+/ctcqWpf8QrHNii7fo 41mnxh9Ph2K70irDlta/Y+pRlE0zVmBG5xdTi+LFm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work (and how to get it used...)
I think this is a good summary of how it should work, except, that I don't think messages should be signed by default, only authenticated (MAC). Users should be clearly aware of making a non-repudable statement. Plus, it may be preferable to use something like matasignatures.org to ensure authenticated e-mail does not alarm recipient with non-compliant e-mail clients. A missing element is motivation for getting something like this deployed... I think spam could offer such motivation; and, I strongly believe that a cryptographic protocol to penalize spammers could be one of the most important tools against spam. I've presented such a simple crypto protocol (SICS) in SCN'04 [available off my site], and now work on open-source implementation (with student Jonathan Levi) of an improved version (SICSv2...), to be published soon. [I can send draft to experts willing to provide feedback...] Best, Amir Herzberg James A. Donald wrote: -- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * 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 be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. * The email client learns correspondent's public keys by receiving signed email. It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. * 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. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages that are a reply to someone using similar software, and neither he nor those he corresponds with notice anything different or have to do anything extra other than that when he gets unsigned messages, or messages with an key different from the previously used key, a warning comes up an unobtrusive and easily ignored warning if he has never received a signed message from that source, a considerably stronger warning if he has previously received signed mail from that source. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx 4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] . - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work (and how to get it used...)
-- On 30 Mar 2005 at 13:00, Amir Herzberg wrote: A missing element is motivation for getting something like this deployed... I think spam could offer such motivation; Phishing is costing billions, and is a major obstacle to electronic commerce. In my judgment, fixing phishing and facilitating electronic commerce is a good fit to the capabilities provided by cryptography. (Of course a large part of spam is phishing and viruses) a cryptographic protocol to penalize spammers could be one of the most important tools against spam. I've presented such a simple crypto protocol (SICS) in SCN'04 [available off my site], And your site is? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG To5/mH1p3iCBlpaC6McgYo2aehoFMV42OcrSW6Ze 4AmE3tC68Tiyw+VQHexWjeQmXnrDHI+41ty416j11 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work
At 07:00 PM 3/28/2005, James A. Donald wrote: In my blog http://blog.jim.com/ I post how email encryption should work I see a couple of problems with your proposal. I'm not sure I like your external trusted mail-server assumptions, but they're probably good enough for many people, and other people will have better comments about them. Your plan is really designed for a small number of addresses per sender, as opposed to a quasi-infinite set of tagged addresses. It's becoming pretty common for anti-spam reasons to give different recipients different mail addresses like [EMAIL PROTECTED] (or [EMAIL PROTECTED]) or [EMAIL PROTECTED] so you can track and whitelist/blacklist people you communicate with, and some ISPs automagically translate between the two formats. Building a user interface that does that unobtrusively is probably a hard problem, or at least not a well-solved one, and building a cryptosystem that assumes a small number of addresses per user could make that style of mailer harder. A good user interface probably has some version of petname support, though, so there's some commonality with key handling. On the other hand, if you assume that most people will get domains, whether 2LD or 3LD or other subdomain, you could do a model that says that a user gets one key per domain, so you could think about hanging the keys off DNS. That may not be the right choice (do you want your email addresses to be easily correlated, and cracking/stealing one address's key to reveal the keys you use for everybody else? Or does the domain pretty much imply that to the skilled recipient anyway so who cares?) And of course it gets into the whole squabble about DNSSEC, and why its deployment failed, and whether it was trying to do a perfect job and therefore less scalable than a mostly-good-enough job, or at least into the politics of those questions if not the technology. The related problem is what to do if you *do* want different keys for different recipients; you could do that with different subdomains, or you could do a non-DNS approach. - Is (sender+recipient+timestamp+message) the right thing to sign? The Subject: line is in the mail headers, but it's probably something that should be part of the message. I'm not sure about some various X-headers. And of course the From: line includes both the email address and the sender's name, and the sender's name may be different for different recipients (in some sense, it may be the recipient's petname for the sender.) - Also, if you're attaching a key strictly to the email address, what happens to old signatures if you move email addresses? I suppose that's part of the point of getting your own domain name, so you can avoid having to change contact addresses when you change ISPs, but if you're using a new email address, how do you forward the signature? One option is to do what you can do in Crypto Kong, where you send a message from old-address signed by old-address, saying that you'll be using new address and new key, but that seems a bit awkward, since you need a convenient way to include the new keys for people who whitelist you or who you only want to send encrypted mail to. Thanks; Bill Stewart - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
how email encryption should work
-- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * 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 be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. * The email client learns correspondent's public keys by receiving signed email. It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. * 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. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages that are a reply to someone using similar software, and neither he nor those he corresponds with notice anything different or have to do anything extra other than that when he gets unsigned messages, or messages with an key different from the previously used key, a warning comes up an unobtrusive and easily ignored warning if he has never received a signed message from that source, a considerably stronger warning if he has previously received signed mail from that source. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx 4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work
Hi James, I read that last night, and was still musing on it... James A. Donald wrote: -- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * 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 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 which is in fact what users get today - nothing. be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. Concur. The notion that a user needs a cert from anyone else for the purpose of email is wrong; this doesn't mean denying them so they can take part in corporate nets for example, but that ordinary users in ordinary email will not get much benefit from certs signed by other agents. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. I would put this in the extra stuff category, and not in the default category. The reason is that it creates a dependency on a server that might not exist and even if a good idea, will take a while to prove itself. * The email client learns correspondent's public keys by receiving signed email. 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. I've not seen anywhere where it sets out what a signature means for S/MIME. For OpenPGP the signature is strictly undefined by the code, so that's a better situation - it means whatever you want it to mean. 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.) (One possibility is to put the cert in headers.) It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) Yes this would help a lot. Any petname set should be displayed distinctly from the default name. (Oh, as a nitpick, a default address is not a petname, it's just a default name. A petname has to be set by the user to exist.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. Right, the UI could do a lot to show what is possible by shading the various email addresses or adding little icons to indicate their encryptability state. * 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. 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. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages See caveat about signing above. I certainly agree that any message that can be encrypted should be encrypted. If you thought
