Encrypting / Signing the mail subject?

[Arturo 'Buanzo' Busleiman]

Subjects are considered metadata. I wouldnt sign nor encrypt nor actually
put anything remotely related to the encrypted body in them.
On Jan 16, 2015 12:04 PM, "Dave English" <dave at wiredthing.com> wrote:

> 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
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150116/44665d0a/attachment-0001.html>