3

I use encrypted email to converse with some people. Unfortunately, the encryption doesn't apply to the message subject.

Now, on one hand, I do want to use meaningful subjects/titles, but on the other hand - I lose half the value of encryption if people know what I'm taking about with someone.

To be more specific, application-wise, I use Thunderbird with Enigmail; but my question is not specific to just that.

einpoklum
  • 8,783
  • 20
  • 84
  • 153
  • 1
    Subject field is part of email header and is subject for antispam systems to be filtered. If you will use encrypted Subject field you will tease filtering systems such `spamassassin` that will rise spam points on your emails. For example encrypted message can't be a binary string, so it would be encoded in base64 which probably trigger SUBJECT_FUZZY_* rules. Why not to use always the same phrase in Subject such as "See inside..." or similar? – Alex Jan 28 '17 at 10:55
  • @Alex: Because I want to have a proper subject line when I look at the message (after it's been decrypted). – einpoklum Jan 28 '17 at 11:04
  • I afraid you asking to change industry standard, neither outlook or popular end-2-end protonmail and other providers encrypting Subject line. In all systems Subject field used in search criteria and decryption would be a bottle neck. I heard that MIT trying such things you want in their [Mylar](https://css.csail.mit.edu/mylar/) system but it isn't standardized yet – Alex Jan 28 '17 at 11:18
  • Seems to be solve. What you want is possible with Enigmail in Thunderbird! It's now a default option. I could see that Evolution can read the encrypted subject while decrypted. For my part, I would also be interested for such a functionality in EvolutionMail or others. Could someone explain how does that functionality work? Is Enigmail the only way to obtain "Subject encryption" ? Is the "Encrypted Subject" stored in the message body or header? Thanks. – albert Mar 07 '19 at 14:49
  • Thunderbird now has support for encrypted subjects by default via protected headers. – Martin Monperrus May 07 '23 at 07:44

1 Answers1

2

Email encryption usually does not include message headers.

However, there are approaches to address this problem. I know of these:

(1) S/MIME standard

RFC 5751 S/MIME 3.2 and https://www.rfc-editor.org/rfc/rfc8551, both describe the following method in section 3.1:

In order to protect outer, non-content-related message header fields
(for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields.  It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header.  Given
the security difference between headers, it is RECOMMENDED that the
receiving client provide a distinction between header fields,
depending on where they are located.

When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection.  This entity SHOULD be
presented as the top-level message, taking into account
header-merging issues as previously discussed.

It's not explained if the "outer" unencrypted subject should be changed in a specific way. I've seen an implementation that changes it to (hidden).

Client support

Unfortunately, there doesn't seems to be good support in most mail clients. Of those I've look ed at, no client replaces the outer subject by the encrypted one as proposed in the RFCs.

The inner RFC822 message is basically interpreted as a forwarded message, leading to a slightly to severely confusing presentation.

  • In Apple Mail (macOS), it's quite nice with the inner subject displayed in a prominent way
  • Thunderbird would display it similarly, but claims it's a "ForwardedMessage.eml" attachment
  • MS Outlook is very confusing because it completely hides the inner message as an attached file

(2) Protected Headers (Memory Hole)

There's an extended draft for PGP messages: Protected Headers for Cryptographic E-mail. Although originally aimed at PGP/MIME, the approach can be applied to S/MIME messages as well, and the draft explains it for both. It's previous working title was "Memory Hole", and it's sometimes still referred to with this name.

The idea is to insert a content part of Content-Type: multipart/mixed with an attribute protected-headers="v1" containing the header that should be encrypted. The outer subject is then replaced (usually by ..., but that is up to the client)

Example:

Content-Type: multipart/mixed; boundary="kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64";
 protected-headers="v1"
From: Elvis Presley <elvis.presley@example.com>
To: John Lennon <jl@example.com>
Message-ID: <0662e834-22a9-3ea1-2e12-a356363156f7@example.com>
Subject: ...
 
--kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
 
Hello,

This is the message!  

Kind regards
Elvis
 
--kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64--

The draft also mentions the RFC822 variant, as described first, but it claims that the fact that clients display the RFC822 parts as forwarded message, thus confusing users. The Protected Headers variant, however, is much more user-friendly because even mail clients not supporting it will just display the encrypted headers as part of the message.

Client support

  • Thunderbird now supports Protected Headers, but only in connection with PGP encrypted emails (although there is no reason why it shouldn't work just the same with S/MIME).
  • I don't know of any other clients supporting Protected Headers
not2savvy
  • 521
  • 1
  • 4
  • 17