how email encryption should work

[Ian G]

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 that the threat was changing emails
etc etc then it might be possible to create a cert
that could just be used for message integrity and
stick some tag in there that says "message integrity
only purposes."  Then, as long as the client at the
other end said "this message was delivered without
change" instead of "this message was signed" then
this might work.

When cryptograpers say a message is signed, users
think that a message has been signed....  getting
around that confusion is quite hard.


>     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.


Yes, the model for an unobtrusive message is the
red cross alert bars added in Firefox these days.
They solve the popup nightmare quite nicely.

iang
-- 
News and views on what matters in finance+crypto:
         http://financialcryptography.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com