Encrypting / Signing the mail subject?

Dave English dave at wiredthing.com
Fri Jan 16 14:21:30 CET 2015


Hi Hanno

I have no real idea whether this is the right place to discuss this, myself.

But here goes:

I’m not sure there is a strong enough need, to justify a change.

At the moment there is a clear split between envelope & body.  Only what is in the body is signed and can be encrypted.  If you start to handle the Subject especially, then you blur the boundary.  That could lead to confusion about the handling of other headers.

Of course, not everyone has a technical view of the structure of an e-mail.  Many users will not have any concept of the envelope, witness use of Cc: versus Bcc: - but I would hope that a user knowledgeable enough to use signing or encryption has at least an idea of a distinction between body & the rest.

The more competent, at least, will always be free to include nothing sensitive or prone to subversion in their Subjects, as and when necessary.

There could be problems with trying to sign what is in the Subject header, some systems will change it, either truncating it because of technical limitations, or amending it, e.g. to tag suspected SPAM.  If the distinction between envelope & body were blurred then users might expect other headers to be protected & that would be problematic to implement.

As an aside, even a signed body presents an opportunity for abuse, because it can contain what is supposed to be the same message in alternative forms, text & html.  Some one can construct a mail with two different texts, albeit unrepudiatably, so that one viewer reads one signed version of what is said & another viewer reads something different.  I can’t see any easy fix to that, other than viewing with suspicion any multi-part.

Never the less - good luck with promoting your change, after all things rarely improve without it.

ATB

> On 16 Jan 2015, at 12:43, Hanno Böck <hanno at hboeck.de> wrote:
> 
> Hi,
> 
> I wanted to share some thoghts about a potential change to the PGP mail
> format I had. I'm not sure if this is the right place to discuss this,
> but afaik there is currently no active openpgp standards list at IETF
> and gnupg is likely the only implementation in widespread use. I recall
> that I have read something alike already somewhere sometime, however I
> don't exactly remember in what context.
> 
> One of the things I find unfortunate about OpenPGP encryption is that
> the subject of a mail is not encrypted and signed. This is imho very
> bad from a usability point of view and also not really neccessary,
> because there are ways this could work without changing too much about
> the way pgp mails work.
> 
> What I have in mind is something like this: Whenever a PGP mail app
> creates a mail it replaces the subject with a defined keyword. This
> could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
> a Subject line inside the encrypted mail body. This is followed by two
> newlines and then the real encrypted body of the mail follows.
> 
> A mail client supporting this format would then replace the
> __ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
> would hide the Subject: ... and the two newlines from the UI display of
> the mail body.
> 
> Doing this would provide some kind of backwards compatibility to old
> clients. A client not supporting this mechanism would still be able to
> read a mail. It would also show the subject as part of the encrypted
> mail body. There would even be some compatibility in the other way. A
> user aware of how this works could manually set the subject keyword and
> the Subject in the mail body in a mail client not supporting this
> mechanism.
> 
> 
> There are some things that'd need consideration if such a mechanism
> would be created:
> * This would move the subject to the encrypted part of a message. A
> mail client may decide that it needs some kind of caching of mail
> subjects available, because it is not feasible to decrypt them on
> demand, especially on large mailboxes. Therefore a client might move
> data from the encrypted context to a nonencrypted storage. This is a
> trade-off, but imho it is still a lot better than not encrypting the
> subject at all.
> * One would have to make a clear decision how the Subject is encoded to
> avoid confusion and incompatibilities. Currently a subject with special
> chars has some kind of utf8-prefix-encoding. A mail body has its own
> encoding. One would have to decide if the subject encoding is just the
> body encoding or if the same format as in the header is used. Technical
> detail, but should be done right and should be unambigious.
> 
> So far my rough proposal.
> What do people think about it? Is this the right place to discuss it?
> If you like it do you think it should become a standard/RFC? Anyone
> interested in impementing it in whatever mail client implementation?
> 
> (and to proove my point why this is desirable just see this mail by dkb
> where he explains why it's bad to rely on subject information in the
> mail content: http://seclists.org/oss-sec/2015/q1/137 )
> 
> cu, Hanno
> 
> --
> Hanno Böck
> http://hboeck.de/
> 
> mail/jabber: hanno at hboeck.de
> GPG: BBB51E42
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150116/b9b0e5c4/attachment.sig>


More information about the Gnupg-devel mailing list