Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Thu, 23 May 2002 23:25:17 +0200

What is the problem I try to solve? I thought that had been clear
through the many mails I sent, but let me try to explain again.

1) Don Davis has a pretty good description of the problem in
	http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
	He lists many good reasons why this is a problem in section 4.

2) Many users seem to think that PGPs sign & encrypt function is atomic.
	We can try to teach them that is never was so, and never will be
	(a bad solution in my opinion) or we can give the users what they
	want/expect and make it possible to have an atomic sign & encrypt
	in PGP.

To word the problem in another way, when Alice send a message to Bob
that is signed and encrypted, Bob should be able to be sure that it
was Alice that encrypted the message.

Description of attack:

Alice send a signed & encrypted message to Charlie. Charlie decrypts
it and encrypts and sends it to Bob, trying to convince Bob the message
comes directly from Alice. Since Bob see the message is apparently
made by sign & encrypt he thinks it must be Alice that has encrypted it.

Some solutions:

	- Teach Bob not to trust PGPs sign & encrypt to know who the sender
	  of the message is when it is not in the plain text of the signed
	  message.

	- Make PGP use Encrypt, Sign and Encrypt. (Slower
encryption/decryption
	  and bigger messages.)

	- Add fingerprints of recipient keys in signature packets (Requires
a change
	  in the protocol)
-- 
Terje Bråten

---

From: "Michael Young" <[email-masked]>
Date: Fri, 24 May 2002 20:56:08 -0400

To: [email-masked]
Subject: Re: secure sign & encrypt
X-Comment: I, too, was hoping that this would die out before
  the urge to weigh in overwhelmed me, but it hasn't :-).

I generally side with Jon, Hal, and Derek here.  The intended
recipient is only one of many pieces of context that a user
might mistakenly believe was included in the signed material.
Adding a subpacket to address just this one piece of context
doesn't strike me as necessary, particularly since there are
very reasonable solutions within the existing framework:
notation subpackets; or, layered (encrypt-sign-encrypt) processing.

Ultimately the problem is one of user misunderstanding, arguably
exacerbated by the user interfaces in specific implementations.
Either the users need to be better educated, or the implementations
need to do a better job expressing exactly what has been signed
(and, perhaps, for naive users, the indirect implications).
Neither requires a change to the specification, just to the
implementation (of the tool or the user :-).

I appreciate Terje's desire to encode context so that it can be
checked automatically, and a desire for a convention for doing the
encoding, for implementations that want to do so.  I would have no
objection to publishing a convention for encoding the intended
recipients in a notation packet.  That wouldn't have to be part of the
base RFC.  That said, I wouldn't *strenuously* object to this being
documented in the base RFC, or even to a new OPTIONAL subpacket.  I
just don't think it helps enough: it doesn't cover other context;
and, it doesn't help for "legacy" messages.  Here "legacy" means
both old implementations (that don't support the packet) and
old V3 signatures (which don't have subpackets at all).

> was Alice that encrypted the message.

I disagree that this is a fundamental goal -- it is a derived one.
The real goal is more likely that Bob wants to know that the message
is intended for him.  Knowing that Alice encrypted it is neither
necessary nor sufficient to meet this real goal.  I think this
difference is what Derek was getting at when he asked about goals.

> - Teach Bob not to trust PGPs sign & encrypt to know who the sender

Perhaps, as a means of teaching Bob:
  - Warn Bob about the limitations, something like:
    "The signature does not name you as the recipient.  This document
     may have been forwarded to you by the original recipient.
     Do not assume that it was intended for you."

    This may seem verbose, but naive users often have problems
    with shorthands for complex concepts: "(Invalid)" comes to mind :-).

    Again, this is the best that you can do for legacy messages, anyway.

> - Make PGP use Encrypt, Sign and Encrypt.

It's fine to have a particular implementation adopt this layering (or
to offer it as an option).  It would be very wrong to legislate this
particular layering.  While users may not understand the implications
of particular layerings, implementors clearly should understand, and
should be trusted to choose the layering appropriate for their
perceived users' needs.  You may want a tool that offers
encrypt-sign-encrypt (to identify the intended recipient); someone
else may want a tool that meets other goals (e.g., anonymity or
plausible deniability).  Any good tool should make it clear what
function it is performing, but that's not a *protocol specification*
issue.

> - Add fingerprints of recipient keys in signature packets (Requires

Or,
  - Offer to copy context into the plaintext, or into notations.
    For example, an MUA might offer to copy the "To", "cc", and "Subject"
    headers.  It could even inject an "X-To-PGP-Key" header to record the
    key fingerprint/ID for automatic verification by like-minded agents.
    There's no deep reason that this requires a protocol change.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 29 May 2002 14:04:49 -0700

The S/MIME WG has wrestled with the same issues, coming to the same 
problems that have appeared here. The latest thinking there can be 
found in the the tread that starts at 
<http://www.imc.org/ietf-smime/mail-archive/msg01238.html>.

--Paul Hoffman, Director
--Internet Mail Consortium