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

From: [email-masked]
Date: Tue, 9 Apr 2002 15:33:34 -0500

From: John Dlugosz

IMO,

If forwarding the decrypted plaintext also removed the signature, there
would be less trouble.  The content could be reputiated, since it can't be
distinguised from the forwarder just making it up.

But I think PGP uses "sign, then encrypt" which means software could
decrypt but leave the signature intact.  As I recall, this was thought to
be a non-problem with respect to re-targeting, because you can put the
recipient's name in the message at the application level.  e.g. "Dear Sue,"
is part of the message, so it can't be mistaken as a message to Joan.  But
that doesn't handle the issue of private information in the message.  It's
possible for Sue to reveal the signed message to someone else, who can
verify the signature, without needing Sue's key.  I would prefer if that
were impossible--without Sue's key, the message can't be authenticated
either.

Marc Mutz <[email-masked]>@mail.imc.org on 04-09-2002 12:47:01 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:   [email-masked], [email-masked]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless

[ 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: Jon Callas <[email-masked]>
Date: Tue, 9 Apr 2002 14:27:04 -0700

>were impossible--without Sue's key, the message can't be authenticated

OpenPGP specifies that the signature goes inside the envelope. The reason
for this is that if the signature is outside the envelope, then the
attacker knows both the source and destination of the message. In short, it
provides cryptographically enhanced traffic analysis.

Yes, you're right, someone can decrypt a signed message and then send on
the signed, decrypted message. They can also take a screenshot of the
screen and send the image on to someone else. I know many people who do not
sign messages for this very reason. We added a non-signature integrity
check to OpenPGP messages so you'd have some way of knowing you got the
message intact without requiring the sender to sign it.

There are security risks to signing messages. A good friend of mine is of
the opinion that you should never sign anything that you aren't willing to
forward on to City Hall for inclusion in the public record. He never signed
anyone ele's key for this reason, let alone a message. I'll add that this
guy was an VP at an investment bank, not a cypherpunk with outlaw fantasies.

I'm not quite that extreme, but I don't sign anything that I wouldn't sign
if it were on paper, not on bits.

Mathematics cannot solve real-world security problems. If you're confessing
secrets to someone who gossips, you have security problems. If you send
signed, encrypted messages to someone who will decrypt them and send them
(or send a screenshot of your messagae) on, then you have the same security
problem.

A trusted channel to an untrustworthy person is not secure. And to
paraphrase Laotse, you cannot create trust with cryptography, no matter how
much cryptography you use.

	Jon

---

From: Graham Klyne <[email-masked]>
Date: Wed, 10 Apr 2002 10:19:19 +0100

>much cryptography you use.

Excellent!!

This is the first time I've been aware of a cryptosystems person make this 
point.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Paul Shields <[email-masked]>
Date: Wed, 10 Apr 2002 10:46:26 -0400

Without handling instructions that cause the signature to be removed,
someone forwarding the
message could cause trouble for the original sender.

I raised this as an issue a few years back on the PGP MIME list, but
the folks there were
unconvinced. It seems they wanted to be able to keep the signature
after decryption.

Should we have a selectable option on sign-encrypt that specifies
that the signature must be
removed from the plaintext after verifying it?

- --
Paul Shields

[email-masked] wrote:

  From: John Dlugosz

  IMO,

  If forwarding the decrypted plaintext also removed the signature,
there
  would be less trouble.  The content could be reputiated, since it
can't be
  distinguised from the forwarder just making it up.

  But I think PGP uses "sign, then encrypt" which means software
could
  decrypt but leave the signature intact.  As I recall, this was
thought to
  be a non-problem with respect to re-targeting, because you can put
the
  recipient's name in the message at the application level.  e.g.
"Dear Sue,"
  is part of the message, so it can't be mistaken as a message to
Joan.  But
  that doesn't handle the issue of private information in the
message.  It's
  possible for Sue to reveal the signed message to someone else, who
can
  verify the signature, without needing Sue's key.  I would prefer if
that
  were impossible--without Sue's key, the message can't be
authenticated
  either.

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2002 11:51:38 -0400

> removed from the plaintext after verifying it?

How would you enforce this?  This is just like the "for-her-eyes-only"
flag on literal text.  It's a notation to keep the good guy honest,
but wont protect you from someone who really wants to get around it.

For example, many a time I've used 'pgp -fm input.asc >& output.txt'
to get around the for-her-eyes-only "bug".

The only way to really enforce this is to mathematically tie the
signature to the encryption.  This would require a whole new line of
mathematics (assuming you want to continue to hide the sender's
identity to non-recipients).

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 10 Apr 2002 18:06:51 +0200

On 2002-04-10 10:46:26 -0400, Paul Shields wrote:

>that the signature must be removed from the plaintext after 
>verifying it?

What, precisely, prevents the recipient's implementation from 
ignoring that flag?

In the suggestions circulated in this thread, some folks are making 
the same basic design error all over the place: You want to place 
trust in software which is under the complete control of an 
individual you don't trust.  Don't do it.  It's impossible.

The features which are being suggested _may_ help against 
unintentional errors the recipient may make (like, storing, by 
accident, the wrong love letters on the wrong hard drive, which [I 
seem to recall] was the original reasoning behind the "for your eyes 
only" [or whatever it was called] function of pgp 2).

They don't, however, help against malicious behavior on the 
recipient's side.

-- 
Thomas Roessler                        <[email-masked]>

---

From: Paul Shields <[email-masked]>
Date: Wed, 10 Apr 2002 13:16:28 -0400

Derek wants this to be enforced or not to have it at all.
Ned points out that users will be angry if you try to enforce it.

All I wanted was friendly handling instructions, a convenience
feature just like 'eyes-only'.  It won't try to prohibit
forwarding, it is simply a request that the receiver remove the
signature after decrypt+verify.

Yes, Derek will be able to get around it unless someone figures out
how to tie the signature to the encryption. Yes, it
won't be supported by some implementations. But does it make matters
worse than they are now?  Is it something that
has value ONLY if it is enforceable?

- --Paul.

Derek Atkins wrote:

  > removed from the plaintext after verifying it?

  How would you enforce this?  This is just like the
"for-her-eyes-only"
  flag on literal text.  It's a notation to keep the good guy honest,
  but wont protect you from someone who really wants to get around
it.

[email-masked] wrote:

  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: Sam Roberts <[email-masked]>
Date: Wed, 10 Apr 2002 22:59:01 -0400

There actually is a cryptographically sound technique that helps
here, I was talking about it with a cryptographer at work last
week while reading RFC 2630, and not getting the difference
between authenticated and signed data.

S/MIME only uses the signed and enveloped types from CMS, but RFC2630
specifies authenticated as well. Its not well described there, but it is a
way of "signing" something using a key agreement algorithm, such that the
signature can ONLY be verified by using the sender or the receiver's
private key.

Now, since the receiver knows he didn't authenticate it, he knows the
sender must have.

What this gives you is repudiation. If I authenticate something to
you, you know I authenticated it. But if you forward it somebody
else, they can't verify the signature, they have no way of knowing
for sure that I authenticated it, and I can deny it. Even if the
recipients private key is compromised, they still can't prove
that *I* authenticated it, since either one of us can create the
"signature", all they know is one of us made the authenticated data.

I hope my explanation was clear, its easier on a white board!

This CMS authenticated data is only possible with key agreement
algorithms, i.e., you can't do it with RSA. I could be wrong
about it not being a defined payload for S/MIME, but I don't
think so. Too bad. It also has a very odd "feature" or "bug" when you
authenticate the same content to multiple receivers in the CMS message.
I'll explain if anybody is interested.

Sam

-- 
Sam Roberts <[email-masked]> (Vivez sans temps mort!)