On 03.12.2021 12:04, Bernhard Reiter wrote:
First I wanted to gather some feedback, especially about the following
section, where I've added a recommendation what to use instead
of incompatible header encryption:
| Transport information in a decentral network - just like the writing on the
| outside of a postal mail envelope - cannot be protected in principle.
| When reflecting on this, chose a subject that is plausible in context,
| but without sensitive contents, to best veil potential unwanted observers.
| (Your thinking is right: The more sensitive this is, the more you have
| to build up a plausible context for your unavoidable traces first.)
I didn't read the wiki page yet, but I'd like to comment on that paragraph. I
agree in part, but not completely. The idea is nice, but can't be realized in
practice.
From my personal experience, it is very hard and consumes time to find appropriate
subject lines. After all, when using OpenPGP in business, recipients invest 5 seconds per
message at maximum when scanning the list of received messages to decide what message to
read first. "Wrong" subject lines are not helpful in this context. That means
that your suggestion may be valid for private communication, but not for business.
Rather, it is often good style and really simplifies things if some important (sensitive) data is
in the subject line. As an example, imagine that you are communicating with your health insurance
company. The staff there usually is very grateful if they see your insurance number in the subject
line, plus a few keywords (in German, for example, "Kündigung",
"Leistungsantrag" etc.). Not following this convention costs them time and effort and is
bad style.
Apart from that, you'll have some trouble yourself with that strategy. Imagine you have to find a message you have sent
two years ago. That could be hard if you have "faked" the subject lines. Furthermore, the recipient will
hopefully answer your message one day, and will typically do this by just hitting the "Reply" button. That
means the answer comes back with the same "fake" subject line you originally had chosen, and that game will
continue until the communication on this subject has ceased. In the end, you have 50 sent messages and 50 received
messages with a "wrong" subject line.
Your comparison with snail mail is the right way to understand the issue: Did you ever
receive a letter from your health insurance which carried the actual subject on the
*outside* of the *envelope* (example subject of a letter from your health insurance:
"Payment for your HIV treatment")? I didn't, and I'll have a very serious talk
with the sender if I ever do.
*Every* piece of data should be protected, especially in electronic
communication, except the transportation data which technically is absolutely
necessary to get the transport done. In the same way the postal service does
not need to know the content of a letter (including the subject) to transport
it from the sender to the recipient, SMTP servers do not need to know the
subject to transport messages.
SMTP basically needs only the sender address (strictly looking at it, not even
that, but it is important for bounces and replies) and the recipient address.
Sad to say that SMTP servers usually dynamically add headers during transport
which already can put somebody at risk, but I guess we'll have to live with
that for the moment.
A subject line really does not fall into the category of transportation data.
SMTP servers don't need to know it to transport the message, and it can (and in
most cases, will) contain sensitive data. We shouldn't call something
transportation data solely because it is in a header.
I am very grateful that we can finally encrypt the subject line with most OpenPGP
implementations since several years. Actually, not being able to do this kept me from
using PGP (in E-Mail) for a while. Now I always encrypt the subject line, and so do my
communication partners. If there are MUAs out there which can't cope with that,
refraining from encrypting the subject would be the wrong reaction. Instead, people using
such a MUA should be educated to use another MUA. PGP implementations have undergone
changes which were much more "breaking" than encrypted subject lines.
Best regards,
Binarus
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
