Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless

From: Marc Mutz <[email-masked]>
Date: Tue, 09 Apr 2002 19:47:01 +0200

[ OK, I put this where it belongs: this touches OpenPGP and Internet messages,
 so I'm forwarding this to the ietf lists ]

We have a problem and we think we are not alone with it (see the mozilla link 
below):

What if, in a mail user agent, the user wants to forward an encrypted message?
Allow it? Deny it?
Re-encrypt or remove encryption?

The problem is, of course, that the original sender might not like his 
encrypted text being sent out in the clear again...

Was this discussed here already? What was the consensus reached, if any?

Marc

On Tuesday 09 April 2002 13:01, Volker Augustin wrote:
> > Peronally, I think the best way is to ask the user
> > what to do when forwarding (inlined) an encrypted message. We cannot
> > prevent that he/she will forward the plaintext using a workaround. So we
> > better delegate the resposibility for this action to the user itself.
> >
> > There is still the question, what should be the default way. Another way
> > would to set the default to the last recently used way. Hm, I'm sure
> > you'll find a good solution.
>
> That might be a good solution. When trying for forward bring up a dialog
> asking whether to allow forwarding just this time or also for the future.
>
> I just did an intensive search via google. Here are some of my findings:
>
> 1. Some mail programs have an option to prevent forwarding of encrypted
>     messages. I could not find a single one explicitely preventing it. 
> Some commercial application however give the system administrator the
> possibility to enforce this option system-wide.
>
> 2. RFC 1421 about PEM states (http://www.freesoft.org/CIE/RFC/1421/55.htm)
>
>    "Some level of support for generating and processing nested and
> annotated PEM messages (for forwarding purposes) is to be provided, and an
> implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or
> MIC-CLEAR for forwarding."
>
> 3. There is an IETF draft about "Intended Recipients Attribute for the
>    Cryptographic Message Syntax (CMS)"
>    (http://www.ietf.org/internet-drafts/draft-ietf-smime-ira-00.txt) saying
>
>     "The problem of intent that as expressed in [MALFWD] is beyond the
>     control of S/MIME protocol or its implementers.  The use of the digital
>     signatures and encryption is correctly in the hands of the user.
> However, the intended recipients attribute offers a mechanism to reduce the
> likelihood of undetected malicious forwarding."
>
> 4. The mozilla team has the same problem:
>     http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html
>
>     "open issues:
>     1) forwarding an encrypted message?
>     2) standards for content type S/MIME. PGP. GPG. OpenPGP.
>     3) Eudora and Outlook, etc. what do we need to do to support reading
> encrypted message from other clients? "
>
> Regards,
> Volker
> _______________________________________________
> KMail Developers mailing list
> [email-masked]
> http://mail.kde.org/mailman/listinfo/kmail

- -- 
Marc Mutz <[email-masked]>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 9 Apr 2002 20:39:55 +0200

Marc Mutz <[email-masked]>
> encrypted text being sent out in the clear again...

The original sender might not his text being sent out at all. He sent it
to you; you're showing it to some third party.

Personally, I suggest using as much encryption as reasonably possible. In
general, and naturally also in this particular case.

--Arnt

---

From: "Leon Kuunders" <[email-masked]>
Date: Tue, 9 Apr 2002 21:08:28 +0200

I don't know if this was discussed, but for me this is not a question of
encryption, but of trust. If you don't like someone else to forward your
messages, send them on paper. With a company logo, a watermark and a unique
number.

It is the risc of living :)

-Leon.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marc Mutz
> Sent: 09 April 2002 19:47
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > 2. RFC 1421 about PEM states
(http://www.freesoft.org/CIE/RFC/1421/55.htm)

- --
Marc Mutz <[email-masked]>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Apr 2002 21:32:00 +0200

> encrypted text being sent out in the clear again...

Then the original sender should not send the text to someone who will
do that.

I don't see how the standard could prevent the user from doing
this. If it is prevented, then it is only the applications' doing, so
it wouldn't be difficult to override it.  This isn't a technical
problem. Whenever you introduce encryption between two parties you
have this issue.

Whether to re-encrypt or remove encryption is up to the user
forwarding the message.  What the defaults should be probably depend
too much on the application to give any generic recomendation on.

Just my two cents.

---

From: "Clinton E. Troutman" <[email-masked]>
Date: Tue, 9 Apr 2002 16:08:03 -0500

- --- Reply created Tuesday, 09 April 2002, 15:59:49 ---

- ------- Original Message --------
On Tuesday, 09 April 2002, 14:32, you wrote:

SJ> Then the original sender should not send the text to someone who
will
SJ> do that.

SJ> I don't see how the standard could prevent the user from doing
SJ> this. If it is prevented, then it is only the applications'
doing, so
SJ> it wouldn't be difficult to override it.  This isn't a technical
SJ> problem. Whenever you introduce encryption between two parties
you
SJ> have this issue.

SJ> Whether to re-encrypt or remove encryption is up to the user
SJ> forwarding the message.  What the defaults should be probably
depend
SJ> too much on the application to give any generic recomendation on.

SJ> Just my two cents.

- ------- End Original Message --------

Absolutely agreed.

Not a technical problem.

It is a problem of data released "to the wild" and what another party
may "do" with that data once released.

The allowable disposition of the data beyond the party of first
release should be specifically stated to prevent "missteps" by that
party.

And, if you are concerned that the data *not* be released beyond that
first party, perhaps you should consider either:
- - another method of release, or
- - your relationship with the party to whom you are releasing the
data,
or
- - don't release that data in the first place.

(Interesting how this seems to parallel the current debates on
copyright...)

- -----
Clinton E. Troutman
mailto:[email-masked]
- -----
"You can tell the Mafia is running the cockfight if the duck wins." -
Anon.
ÀFÿ\„$%

---

From: Magnus von Koeller <[email-masked]>
Date: Wed, 10 Apr 2002 10:33:30 +0200

On Tuesday 09 April 2002 19:47, Marc Mutz wrote:
> The problem is, of course, that the original sender might not like
> his encrypted text being sent out in the clear again...

I'll just state my opinion on this matter because I want to give
Volker some support ...

I say: Allow forwarding. Remove encryption if you do inline
forwarding (forward as attachment shouldn't alter the source at all).
If possible, re-encrypt (i.e. the 'encrypt message' button should be
activated by default but you should be able to turn it off). You
should probably display a warning with a 'Dont show me again'
checkbox, too.

Reasoning: If KMail doesn't let you do this, then you can still just
copy&paste. So all you do is annoy the user. If the sender of an
encrypted email _really_ doesn't want you to forward that message to
others or doesn't want it forwarded in unencrypted form then he has
to tell you explicitely in his message. He'll have to do this anyway
because he can't assume that all mailers handle this the way KMail
does and because the user could still do copy&paste. It would be a
good idea to make the user aware of the implications, though, so
that's why I'm in favor of the warning message.

- --
- -M

- ---  Magnus von Koeller ---
email:    [email-masked]
address:  Georg-Westermann-Allee 76
          D-38104 Braunschweig / Germany
phone:    +49-531-2094886
mobile:   +49-179-4562940
web:      http://www.vonkoeller.de

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Apr 2002 09:50:50 -0400

> encrypted text being sent out in the clear again...

I don't think this is something we can control.  If you encrypt something with
a recipient's public key, you're implicitly giving the recipient the ability
to decrypt that message and redistribute it to his heart's content.  You can
issue instructions to the recipient about redistribution of the messgae, but 
you can't control whether the recipient follows those instructions.

Nor is it clear that this is a "problem".    At least, there appear to be
more "problems" associated with mechanisms that do purport to control what
a recipient can do with a message than mechanisms that merely provide 
protection against interception of a message in transit from sender to
recipient.

Keith

---

From: [email-masked]
Date: Wed, 10 Apr 2002 09:10:21 -0700 (PDT)

> protection against interception of a message in transit from sender to

Exactly. This entire problem space has a character similar to that of copy
protection, digital rights management and all that. There are also lessons to
be learned from the Multics work on environments that try to support multiple
levels of secrecy and integrity simultaneously. (Some of the stories told by
the folks who worked on things like text editors for mixed level data are
particularly amusing.)

All of this stuff falls down at some point because you just can't
compartmentalize people's brains. Prohibit forwarding of content and people
will save stuff to files and then mail the files. Prohibit saving to files and
people will cut and paste. Prohibit cut and paste and people will type what one
window says into another. Prohibit people from having mutiple windows up at the
same time for this purpose and they will write stuff down on paper (which
introduces its own set of problems). Prohibit writing stuff down (good luck)
and people will try and remember it, and then enter it incorrectly later.

You can't win. And given how much this pisses off users, making them even less
receptive to following whatever rules they're supposed to be following, you
shouldn't even try.

				Ned

---

From: Marc Mutz <[email-masked]>
Date: Wed, 10 Apr 2002 19:33:17 +0200

On Wednesday 10 April 2002 18:10, [email-masked] wrote:
<snip>
> > more "problems" associated with mechanisms that do purport to control
> > what a recipient can do with a message than mechanisms that merely
> > provide protection against interception of a message in transit from
> > sender to recipient.
>
> protection, digital rights management and all that. There are also lessons
> to be learned from the Multics work on environments that try to support
> multiple levels of secrecy and integrity simultaneously. (Some of the
> stories told by the folks who worked on things like text editors for mixed
> level data are particularly amusing.)
<snip>
> You can't win. And given how much this pisses off users, making them even
> less receptive to following whatever rules they're supposed to be
> following, you shouldn't even try.
<snip>

Actually, we already knew this ;-)
Both camps here agree that you can't stop the receiver from sending the 
formerly encrypted message wherever she wants - in the clear.

Why I am sceptic about allowing forwarding formerly encrypted mails 
unencryptedly or after re-encryption is that - for me - forwarding shouldn't 
change the original message. If you want to change the message, reply to it 
and edit the recipients. If you forward, you actually want to annotate the 
original message with a few lines of notes, then send the stuff on the the 
recipient, much like sticking these yellow post-it strips to a folder and 
write "you do that!" on them before telling the secretary to carry it to the 
next room.

Marc

- -- 
Marc Mutz <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Apr 2002 13:52:00 -0400

> change the original message. 

I agree with this much.  A UA that claims to be forwarding a message shouldn't
misrepresent the message's content.  If the subject message is encrypted, the 
corresponding content of the forwarded message should also be encrypted.
It would be fair for the UA to refuse to forward such a message to someone  
who wasn't a recipient - or at least to warn the forwarder that the recipient
probably won't be able to read it.

OTOH if only part of the message is forwarded, say the body or an attachment,
the original encryption has to be removed anyway.  

It seems like the issue here is really one of how the forwarded message is
represented to the ultimate recipient - does it look just like any other
forwarded message, or can the recipient tell that it's been altered?

Have we ever defined exactly what a forwarded message should look like anyway?

Keith

---

From: Marc Mutz <[email-masked]>
Date: Wed, 10 Apr 2002 21:12:39 +0200

On Wednesday 10 April 2002 20:39, Marcel Waldvogel wrote:
<snip>
> I like bringing up the secretary/post-it metaphor. But assume the letter
> was encrypted, or, in "real-world terms", written in Suaheli, a language
> which nobody else in your office speaks. Putting a "you do that!"
> post-it on the letter won't be useful to your secretary,
<snip>

You don't know my boss. He recently forwarded me a Windows Virus infected mail 
because he couldn't print the attachment (a audio/x-wav labelled .doc.pif 
file). Thank God he works under Linux ;-)

Marc

- -- 
Marc Mutz <[email-masked]>