crypto flaw in secure mail standards

[lcs Mixmaster Remailer]

David Wagner wrote (on sci.crypt):

> Can you help me understand this?  Obviously I must be missing something.
> Why do you need to know whether you are going to encrypt?  In particular,
> one obvious proposal would be the following: When you sign, include any
> relevant contextual information (e.g., date, time, To:) in the signature.
> Does this not work?

I agree that something like this is the best solution.  In particular it
is much better than what was actually proposed in the paper, which was
to put the encryption key into the signature, or the signature key into
the encrypt, or to sign or encrypt twice.  Those solutions advance the
illusion that this is a cryptographic problem related to sign+encrypt,
when it is not.  (Others have observed that the same kinds of problems
arise even if the message is not encrypted at all.)  It is a confusion
about what is protected specifically in an email environment, or perhaps
it is a failure to protect some information that could or should be
protected.  More on this below.

Adding To:, etc. to the signature is the best solution in an email
environment.  As other discussions have noted, there are other fields
which could be important as well, such as Subject, Keywords, References,
In-Reply-To, etc..  In fact some have proposed that the entire set of
email headers should be protected by the signature.  This produces the
least ambiguity and possibility of error.

One cost in the context of this solution is that on the sending side the
software may have to be restructured somewhat.  Presently it is likely
that signature and encryption are done before the message is formatted
for transmission.  Many of the mail headers may be stamped on only at
that last point.  The software may have to be rearranged to make sure
that everything is available at an earlier point in the processing.
Granted, this is more of a problem in the context of retrofitting an
existing system.  It might be argued that this problem should have been
recognized from the beginning and secure email been designed to protect
the mail headers all along.

The other cost happens on the receiving side: what to do when the
protected headers don't match the outer ones?  Is this worth raising a
red flag over?  Or perhaps should the inner ones silently overwrite the
outer ones?

It might be that a certain amount of mismatch commonly occurs.
Mail headers are far from sacrosanct, and gateways, mail exploders and
forwarders do sometimes rewrite them.  If we raise a red flag every time
then people will learn to just ignore the warnings.  If we silently
overwrite then we might lose some of the advantages of the rewriting
which is done (for example mailing lists sometimes rewrite Subject to
tag it with the name of the list, to move a "Re" past the list name, etc.)

These issues can probably be solved but they require some thought and
care in implementing this proposed new capability.

> P.S. Regarding the example about the court: That's not the example I find
> most compelling, because in a court case there are enough resources that
> the potential for such a the failure mode would perhaps be discovered.
> Rather, I'm most worried about everyday users being confused by such an
> attack, where there is no issue about taking things to court.

Okay, but again, we are talking about confusion here.  The real problem in
these examples is a mismatch between user's expectations and/or beliefs,
and what the software actually does.  The proposed solution, especially
the crypto-only one, is to partially change the software so that it
slightly more closely approximates user's mistaken beliefs.  However this
is only a partial fix and still leaves the fundamental problem in place.

Actually the problem has not been diagnosed correctly.  The issue is
not just that people will mistakenly believe that the software protects
the recipient identity.  The more important problem is that the software
fails to routinely protect the recipient identity (and other information).

Here is how the important problem manifests itself: Alice is a manager,
and before leaving on vacation she sends mail to Bob, her subordinate,
saying, "I got the go-ahead from the VP.  We are to put the plan we
discussed into action immediately.  I'll expect to see a full status
report when I return in a week."  She comes back a week later and Bob
didn't do anything!  "Didn't you get my email?"  "Sure, but I wasn't
sure it was legitimate."  "But didn't you see I signed it?"  "Yeah,
but I couldn't be sure you sent it to me.  It might have been meant for
someone else and redirected to me."

In the real problem, the failure is that the software did not routinely
protect the fact that Bob was the recipient.  Hence he could not go on the
assumption that he was the legitimate receiver, and Alice's intention was
not met.  The difference from the earlier examples is that in those cases,
someone mistakenly thought the recipient was protected.  In this example,
someone correctly thought the recipient was not protected.  That is why
the problem is more important and fundamental, in that it does not rely
on persistent misunderstandings, but rather the problem is that the
default behavior of the software did not represent the sender's intention.

This real problem will remain in place even once people have learned that
the fake one is not an issue.  The only solution at present is to
manually copy the relevant header information into the message.  David
is right that a better fix is to do so automatically.

But again, let us not be misled into thinking it is a cryptographic
failure with a cryptographic fix.  It is actually a problem that is very
specific to email, and the fix is specific to the email environment.
The problem is that the sender has no easy way to protect relevant email
header information, and so the fix needs to be to provide a way to do so.
This will require some redesign of email software and of how it interfaces
to encryption.  The sender side needs to figure out the headers before
it goes to encrypt/sign, and the receiver side needs to be prepared to
do something reasonable when the inner headers don't match the outer ones.

BTW, adding this capability would also allow for greater privacy
protection of messages as well.  The failure to encrypt Subject lines
is something that people have complained about for years.  Even the
recipient data could be hidden until the mail got to the receiving
mail server, which could decrypt an outer envelope to discover the
To: lines in full detail.  Or someone could use an anonymous remailer
to hide the source of the mail from outsiders, but put a true From:
line in the inner envelope so that the recipient sees who it is from.
There are many additional advantages to being able to put mail headers
inside encryption/signature wrappers in a transparent way.



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