[Cryptography] The next generation secure email solution
Ralf Senderek
crypto at senderek.ie
Thu Dec 26 06:24:47 EST 2013
I am looking into the future again: (Email Encryption Preferences)
Phillip Hallam-Baker had proposed three pieces of change to make
email secure, I will have a closer look at the one piece that
IMHO has the most impact on future email security, the proposal
that a (receiving) user can declare his email encryption preference
that will be honoured by the email transport infrastructure and not
the sender's email program.
Alice, the geek, has all crypto gear in place to decrypt X509 and PGP
encrypted email, while Bob, the sender, does not use anything to encrypt
on his endpoint (a smartphone) he might not even know what encryption is.
The fact that Alice declares her preference to receive PGP encrypted
email will be enough to trigger an encryption process done on the
email transport infrastructure, very soon after Bob hits the send button
on his smartphone and the email goes out unencrypted.
How can this be done?
Bob uses the email address alice at example.com in the usual way, his clear
text email hits the first MTA. How does this MTA know reliably, that Alice
wishes to have her incoming email PGP encrypted? I can imagine the following
scenario:
The MTA queries the website "example.com" with the URL
wget https://example.com/emailpreference/alice@example.com
If unsuccessful, it will try http. If unsuccessful, it will send the unencrypted
email off as usual. That's what we have today.
If the query is successful, the MTA expects a (formal) message signed by the key
that is appended to the message. It verifies the signature and gets to know Alice's
email encryption preference. So anyone who is capable of storing a certain
message, with a self-signed key, in the file system of the domain's web
server can define (and change) Alice's EEP. If Alice runs her own web site
this is the most comfortable and secure way for Alice to express her
encryption preference to the world. From now on, encrypted emails are piling up in
Alice's inbox, none of which have been encrypted by the sender himself.
This scenario allows for certain (easy) MitM attacks, but it spreads the declarations
over a number of web sites, avoiding one single key store. And if Alice wants
X509 encrypted email from next week, she signs and stores one single message
on her own web site, that's all.
Possible issues:
1) Alice wants her email in plain text, but someone stores a pre-fabricated
preference message on Alice's web server, locking her out from reading her
email.
2) The MTA has to decide which public key is to be used without the help of
any PKI, except the EEP messages. But this decision can be supported by some
register, similar to the one we have already envisioned for the eccentric
authentication model.
3) MTAs cannot be extended to support the new feature. What does it take
to change MTAs like postfix, exim, sendmail etc? Is this a possible
way to go that has any chance of success?
--ralf
More information about the cryptography
mailing list