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

Reply via email to