how email encryption should work

Bill Stewart bill.stewart at pobox.com
Sat Apr 9 01:17:46 EDT 2005


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
         tag at mydomain.com (or tag at mysubdomain.domain.com) or
         myname+tag at domain.com
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 majordomo at metzdowd.com



More information about the cryptography mailing list