On 2022-01-29 at 17:34 +0100, Binarus wrote:
> 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.
How is it that *not* having the insurance number in the subject but
instead e.g. on the first line costs them time and effort?
> 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.
I agree with this, though.
> 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.
That's a good example where it would be preferable to use a subject
like "Payment for your treatment". It's probably not really required to
specify in the subject line *which* kind of treatment it is. And that
broad topic is probably not revealing much for an email received from
"invoices@healthinsurance.com"
> *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.
I agree on principle, but see below.
> 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.
Nothing in the email you receive is actually required. You could have a
Fully-Encrypted-Email-Messages, which on SMTP looked like:
MAIL FROM:<...>
RCPT TO:<lists@binarus.de>
DATA
-----BEGIN PGP MESSAGE-----
hF4DCPKrKdZYGfESAQdATlsTH4qB5t6wpjKRftCMhq4BqoFa28iMd1aIDZaq710w
...
-----END PGP MESSAGE-----
.
QUIT
No plaintext at all. (Well, some Received: headers would be added, plus
a Return-Path: ) You can even do that today.
Your problem is that no client supports it.
> I am very grateful that we can finally encrypt the subject line with
> most OpenPGP implementations since several years.
*Most* implementations? Could you list them? I would have thought that
there are still more implementations not supporting it than supporting.
> 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.
That's fine if you know that the other side will be able to read it (or
you don't care if they cannot read it).
> 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.
Except there's no specification for that, so you can hardly blame them
for not supporting it. There was draft-autocrypt-lamps-protected-
headers, which expired 1.5 years ago.
https://www.ietf.org/archive/id/draft-autocrypt-lamps-protected-headers-02.txt The more pressing issue, however, is that encrypting the subject
makes non-trivial some features that the users have become used to,
like listing the (decrypted) subjects of all your emails (as it now
requires decrypting $N emails, which needs fetching all of them from
the IMAP server, unlocking all the keys…).
It also somewhat obscures the advice that "anything in the headers of
the email is not protected", since it is now protected only
_sometimes_.
Best regards
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
signature.asc (0.64 KB)