Protecting Mail headers (was: Re: Evolution signatures)
Adrian 'Dagurashibanipal' von Bidder
avbidder@fortytwo.ch
Wed Aug 6 08:27:03 2003
--Boundary-03=_CAKM/OZfae8FqZS
Content-Type: multipart/mixed;
boundary="Boundary-01=_//JM/JHTOq3rZfv"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline
--Boundary-01=_//JM/JHTOq3rZfv
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: body text
Content-Disposition: inline
On Tuesday 05 August 2003 21:18, Neil Williams wrote:
[Protecting email headers]
> But again, what do I GAIN from you doing that extra work?
You probably can see what I mean in the answer I wrote to Carl's mail. If n=
ot:=20
Quite a few people are used to essential bits of information being containe=
d=20
in the Subject of a message. Or, to take the famous and stupid example:
=3D=3D=3D=3D=3D=3D=3D=3D
=46rom: alice@heaven.org
=2D---- BEGIN PGP SIGNED MESSAGE -----
I lkove you
=2D---- END....
=3D=3D=3D=3D=3D=3D
I hope it's clear what you can lose because the From: header is not signed.=
=20
Yes, the example is stupid, but I think things like these *do* happen.
Attached is my proposal - comments, of course, are welcome. One extension I=
'm=20
thinking of: in case of encrypted mail, let the "protected" headers=20
automatically override the original headers of the mail when it is displaye=
d,=20
and strip the real mail headers down to the minimum (empty Subject, envelop=
e=20
sender/recipient in To/From, no CC, no References. But this would break the=
=20
(for me) important property of the proposal: if your MUA at the receiving e=
nd=20
doesn't support header protection, everything works as expected. So this=20
extension would be optional in any case.
cheers
=2D- vbi
=2D-=20
random link of the day: http://fortytwo.ch/sienapei/laweesha
--Boundary-01=_//JM/JHTOq3rZfv
Content-Type: text/plain;
charset="iso-8859-1";
name="MIME-OpenPGP-Header-Protection.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="MIME-OpenPGP-Header-Protection.txt"
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
Adrian von Bidd=
er
avbidder@fortytwo.=
ch
April 20=
03
=20
Protecting Email Headers in MIME signed email
Abstract
This document discusses a scheme to add protection to email headers of
digitally signed email[1] by duplicating them into the signed part of the
mail. Implementations that correctly support the MIME[2] and associated
standards but do not support this extension will continue to work properly
without any modifications.
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
1. Motivation
Don Davis' paper[3] on various possible attacks on encrypted and signed ema=
il
communication is discussed every few months on many mailing lists dealing w=
ith
email and/or encryption - a discussion that often ends in strong disagreeme=
nt,
some stating that the 'attacks' described in the paper are not, technically,
an attack on the cryptosystem, the other side claiming that the attack is
genuine and proposing various technical measures to prevent them. To short=
cut
any discussions: This proposal does *not* alter the situation in this regar=
d.
It all boils down to the simple fact that the interpretation of a message
differs if the context where the message is received changes.
Then why mention it at all? I had the idea for this method the first time
while discussing it on some mailing list - if you find the archives, please
(a) send me the URL and (b) you will notice that I changed my opinion towar=
ds
the end of the discussion. In any case, I thought that by protecting the
email headers, everything would be just beautifully solved... If you now te=
nd
to agree with me, please read the section about attack scenarios in section
@@@ to see what the protection of headers can *not* do.
This leads us to the question: why bother, then? The reason is quite simple:
most people do not know how easy it is to fake emails, and especially email
headers. They rely on headers in the same way that they rely on content of
the mail body. While a security concious user can protect the mail body by=
a
digital signature, this is, so far, not possible for email headers - a sour=
ce
of potential confusion.
While this specification deals with both signed and encrypted/signed messag=
es,
it should be obvious that most email headers can not be hidden in an encryp=
ted
message as they are necessary for the handling of the message within the
Internet mail system. For the this reason, header protection is *not*
specified for emails that are encrypted but not signed.
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
2. Specification
Basically, header protection works by copying the entire headers into the
headers of the first MIME part of a multipart/signed message.
2.1 Signalling the use of Header Protection
=46or the convenience of implementors, a Protected-Headers mail header with=
a
comma separated list of the headers to be protected MUST be added to the
headers to be protected. For example:
Protected-Headers: To, From, Subject
To simplify the implementation of parsers, the Header-Protection header SHO=
ULD
come before any header that is to be protected.
2.2 Structure of the Header Protection Information
The header protection information consists of directory information specify=
ing
which headers fall under protection and the be protected headers themselves.
The directory information is contained in the Protected-Headers header, whi=
ch
is repeated from the real mail headers. The protected headers MUST be copi=
ed
unchanged from the respective headers in the message headers, except that
their names are prepended by a 'P-' prefix to avoid namespace conflicts. =20
In a typical email message, header protection information will look like th=
is:
(Note that the Protected-Headers field MUST precede all 'P-' header fields.)
Protected-Headers: To, From, Subject
P-To: lover@example.com
P-From: Alice Nice <alice@example.com>
P-Subject: I love you
Note that the order of the headers MAY not be the same in the actual mail
headers, the Protected-Headers mail header, the Protected-Headers header in
the protected message part and the actual protected P- headers.
NOTE: I have been thinking that some headers, like Subject, From and To cou=
ld
be left blank in encrypted email. I have come to the conclusion, however,
that this should not be done for several reasons: (1) Certain spam filtering
products tend not to like messages with empty headers, so reliability of ma=
il
delivery would be endangered. (2) In the message list view of most MUAs, the
encrypted content of an email is not available. This would lead either to
unsatisfying display of such messages, or equally unsatisfying caching of
originally encrypted content or of decryption keys or passwords. I feel,
however, that a MUA should make it clear while composing a message that its
'encrypt mail' function does only encrypt the mail body and not the mail
headers, especially the Subject header. (3) At the MTA level, most of the
content of To:, From: and similar headers can be guessed as the envelope of
the message in the SMTP transaction will still contain valid sender and
recipient addresses.
2.3 Placement of Header Protection Information
2.3.1 multipart/signed messages
The case of a signed, not encrypted email message is quite obvious: the
protection information is placed inside the first MIME part of a
multipart/signed message (which is defined in [1] to contain the protected
information). So, a typical email message looks like this:
Protected-Headers: From, To, Subject
From: Alice Nice <alice@example.com>
To: lover@example.com
Subject: I love you
Message-Id: <1234@example.com>
Mime-Version: 1.0
Content-Type: multipart/signed;
micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"-----boundary-----"
-------boundary-----
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Protected-Headers: From, To, Subject
P-From: Alice Nice <alice@example.com>
P-To: lover@example.com
P-Subject: I love you
=20
I really do.
=20
-------boundary-----
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
-------boundary-------
2.3.2 multipart/encrypted messages
Adding header protection to an encrypted, not signed message does not add a=
ny
security - the message might have been encrypted by enyone (see the section
about attack scenarious). So, header protection is only specified for the =
case
where the encrypted part of the message is also signed.
2.3.2.1 multipart/encrypted with multipart/signed inside
To indicate header protection is used, a Protected-Headers mail header is
placed with the headers which are to be protected. The header protection
information is, as with signed messages, placed inside the first MIME part =
of
the multipart/signed message.
A typical encrypted email message looks like this:
Protected-Headers: From, To, Subject
From: Alice Nice <alice@example.com>
To: lover@example.com
Subject: I love you
Message-Id: <1234@example.com>
Mime-Version: 1.0
Content-Type: multipart/encrypted;=20
protocol=3D"application/pgp-encrypted";
boundary=3D"-----boundary-----"
-------boundary-----
Content-Type: application/pgp-encrypted
Version: 1
-------boundary-----
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
-------boundary-------
with the encrypted message being:=20
Content-Type: multipart/signed;
micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"-----boundary2-----"
-------boundary2-----
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Protected-Headers: From, To, Subject
P-From: Alice Nice <alice@example.com>
P-To: lover@example.com
P-Subject: I love you
I really do.
-------boundary2-----
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
-------boundary2-------
Note that there is no Protected-Headers MIME part header along with the
'Content-Type: multipart/signed' headeri of the encrypted body part.
2.3.2.2 Single pass encrypted-and-signed email
The 'MIME Security with OpenPGP' RFC [4] defines in section 6.2 how to use
OpenPGP's method of combining encryption and signature within the same Open=
PGP
message. Here, as always, the extension=3Dheader-protection parameter is a=
dded
to the Content-Type header of the header block with the to-be-protected
header, and the P- headers are placed in the MIME headers of the signed and
encrypted message part.
A sample message makes this clear:
Protected-Headers: From, To, Subject
From: Alice Nice <alice@example.com>
To: lover@example.com
Subject: I love you
Message-Id: <1234@example.com>
Mime-Version: 1.0
Content-Type: multipart/encrypted;
protocol=3D"application/pgp-encrypted";
boundary=3D"-----boundary-----"
-------boundary-----
Content-Type: application/pgp-encrypted
Version: 1
-------boundary-----
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
-------boundary-------
and the encrypted and signed OpenPGP message reads
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Protected-Headers: From, To, Subject
P-From: Alice Nice <alice@example.com>
P-To: lover@example.com
P-Subject: I love you
I really do.
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
3 Application of this specification
3.1 Sending mail
When an email is to be sent, the senders MUA has to decide which header fie=
lds
should be protected and which should be left unprotected. As a general rul=
e,
any header field that is regularly modified in the transfer of the message =
to
the recipient SHOULD NOT be protected, while all fields that are not expect=
ed
to be changed SHOULD be protected. However, it should be noted that the
choice of headers to be protected ultimately lies with the sender of the
message.
3.2 Receiving mail
In general, the protected headers SHOULD be compared to the unprotected
headers, and the user SHOULD be warned when a message was modified in
transport. This advice should, however, be taken with a grain of salt as s=
ome
small modification like a differing encoding or line folding might should n=
ot
be reason for great concern, and some headers might be routinely modified by
some mail systems on for legitimate reasons.
3.3 Specific headers
3.3.1 Subject, Organisation, Sender
Headers that provide information which is not intended to be interpreted by=
a
MUA, MTA or other message processing system SHOULD always be protected as it
is expected that they are preserved during mail transport.
3.3.2 To, Cc, From and similar headers.
These headers SHOULD always be protected - users will usually rely on them
containing their original values and often get confused when they contain
unexpected values. Also, while some special applications may require chang=
ing
these header fields, normal operation of the email system does not since the
effective recipient and sender of a message is transmitted in the message
envelope; the most frequently modified header in this category is probably =
the
Reply-To header.
It should be obvious that a 'Bcc' header used sometimes between the MUA and
the local MTA should not be considered for protection.
3.3.4 Date
=46rom a security point of view, the Date header does not contain any relev=
ant
information: the sender of a message can set the clock of his computer to
whatever he wants, additionally the signature of the message usually also h=
as
an embedded timestamp. Also, there are mail systems that are known to
regenerate 'broken' Date headers (for some definition of brokenness). On t=
he
other hand, the recipient of a message usually has a certain trust in the
sender, and so may be ready to trust in the contents of the original Date
header.
3.3.5 References, In-Reply-To
As the interpretation of a message varies with its context, these headers
SHOULD be protected if possible. The Message-Id header is a bit more speci=
al:
while it should never be touched when it is present, some (IMHO broken) MTAs
have a habit of inserting their own Message-Id header even if the MUA did
already add one. Vice versa not all MUAs do add a Message-Id header. =20
Protecing the Message-Id does therefore not always make sense.
=20
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
4 Security considerations and problems
Header protection does not add any security against the sender of a message
maliciously (or, of course, unintentionally through a compromised or badly
configured system) sending bogus header information. Also, I want to stress
again that it is entirely up to the sender which headers are to be protected
in the first place. Because of this it is of utmost importance that a
receiving MUA indicates clearly which headers were digitally signed, and wh=
ich
were not.
Implementations have to be aware that the announcement of header protection=
in
the unprotected Protected-Headers header is only a hint that header protect=
ion
is used in a message, but is in itself unprotected. So, implementations wi=
ll
have to handle both the case where header protection was announced but is n=
ot
used, and the case where header protection is used but not previously
announced. In both cases, implementations SHOULD behave exactly as if the u=
se,
or non-use, of header protection had been correctly announced, or not
announced. An warning to the user that somebody might have tried to modify
the message MAY be appropriate.
Many people will overinterpret the fact that they have received an encrypted
message, because they don't know that with public key cryptography anybody =
can
easily encrypt and then forward an intercepted message. This would suggest
that protecting the Content-Type header is a good idea. However, I am not
convinced that protecting the original Content-Type header solves this prob=
lem
entirely. Also, the next section outlines other problems when trying to
protect the Content-Type header.
Recent versions of mailman [5] rearrange the MIME parts of signed messages =
to
be able to add a user visible footer to list mail. Implementations may want
to consider how to handle the situation where the protected headers are hid=
den
in a signed MIME part deep down in the MIME structure, as in this example:
Protected-Headers: From, To, Subject
From: Alice Nice <alice@example.com>
To: lover@example.com
Subject: I love Alice
Message-Id: <1234@example.com>
X-Mailman-Version: 2.1.1
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary=3D"-----mailman-boundary-----"
-------mailman-boundary-----
Content-Type: multipart/signed;
micalg=3Dpgp-sha1;
protocol=3D"application/pgp-signature";
boundary=3D"-----boundary-----"
-------boundary-----
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Protected-Headers: From, To, Subject
P-From: Alice Nice <alice@example.com>
P-To: lover@example.com
P-Subject: I love Alice
I really do.
-------boundary-----
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
-------boundary-------
-------mailman-boundary-----
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
-----------------------------------------
This is the foo mailing list. To unsubscribe ...
-------mailman-boundary-------
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
5 Concluding Remarks
This proposal certainly does not handle all corner cases, but it should
provide a working method to include mail header data within the digitally
signed part of an email message. As such, the biggest problem with the hea=
der
protection as outlined above is that it is not implemented anywhere...
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
Bibliography
[1] rfc1847
[2] rfc2045ff
[3] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
[4] rfc3156
[5] http://www.list.org/
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT $Revision: 1.4=
$
--Boundary-01=_//JM/JHTOq3rZfv--
--Boundary-03=_CAKM/OZfae8FqZS
Content-Type: application/pgp-signature
Content-Description: signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iKcEABECAGcFAj8woAJgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fW00cAoOFOdRs3txP6ZsyZKvW3zJL/
uzGrAKCf7UvCAolAtYBYBzgFEgFEz6yI5w==
=jPI3
-----END PGP SIGNATURE-----
Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.5&md5sum=5dff868d11843276071b25eb7006da3e
--Boundary-03=_CAKM/OZfae8FqZS--