RE: secure sign & encrypt

Terje Braaten <Terje.Braaten@concept.fr> Wed, 22 May 2002 19:57 UTC

Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28294 for <openpgp-archive@odin.ietf.org>; Wed, 22 May 2002 15:57:00 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MJmtX26295 for ietf-openpgp-bks; Wed, 22 May 2002 12:48:55 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MJmrL26291 for <ietf-openpgp@imc.org>; Wed, 22 May 2002 12:48:53 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYM30>; Wed, 22 May 2002 21:46:23 +0200
Message-ID: <1F4F2D8ADFFCD411819300B0D0AA862E29ABEC@csexch.Conceptfr.net>
From: Terje Braaten <Terje.Braaten@concept.fr>
To: OpenPGP <ietf-openpgp@imc.org>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 21:46:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MJmsL26292
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: Jon Callas [mailto:jon@callas.org]
> Sent: 22. May 2002 21:10
> To: Terje Braaten; OpenPGP
> Subject: Re: secure sign & encrypt
> 
> 
> Hal posted a pointer to my comments on this from last year. 
> I'll weigh in
> again.
> 
> I think this is an issue with semantics. You can't solve 
> semantic problems
> with added syntax, no matter how much syntax you add.

It is important that the syntax will let you express the semantics
you want to use. So yes, this is also a syntax problem.
It is not possible with the current protocol to make PGP applications
that automatically check if the signer and the encrypter is the same
person when sign & encrypt has been used.

> 
> Furthermore, there are risks with this, too. You can still perform a
> redirection attack on a targeted signature. Suppose Alice is 
> trying to do a
> business deal with both Bob and Charlie, and trying to get 
> the best price.
> If Bob sends Charlie a signed message that is targeted to 
> him, it can be
> more embarrassing than if the signature were untargeted. I'm 
> really sorry,
> but if you send a private message to someone who puts it on 
> their web page,
> you might be irked by this.

I do not quite see the relevance of this. Do you think it is bad
that Charlie can prove that the message was sent to him from Bob
and not only signed by Bob?
If Bob want to prevent this he can sign first and then encrypt,
instead of using the sign & encrypt function in PGP.


> 
> One of the things that I try to keep an eye out for is 
> traffic analysis. I
> think it is a feature of OpenPGP that it puts the signatures 
> inside the
> envelope, because if they're outside the envelope, you have

The signature will still be inside the envelope. Only those that
the message are encrypted to will be able to see the signature.

> cryptographically assisted traffic analysis. Targeting in 
> signatures also
> assists traffic analysis, and users who don't understand that signing
> low-context messages is a bad idea aren't going to understand traffic
> analysis issues.

It will still be possible to just sign something. It is only when
you use sign & encrypt the receivers should be able to be sure that
the one who signed and the one who encrypted the message is the same
person.

> 
> Lastly, if you really, really want to do this, there is 
> already support in
> the OpenPGP protocol for it! This is one of the myriad things 
> notations are
> good for. Software can make a signature with a human-readable 
> notation in it
> that is boilerplate. It could say, "Created on <date> by <source> for
> <target>." There's your targeting, just convince some 
> implementer to do it.

But the point is not to make some human readable boilerplate. The
point is that OpenPGP software automatically should be able to detect
if the message has been faked to look like it is created by
sign & encrypt when it really is not.


> Just don't make me use it, thanks. I'll have even less reason to sign
> things.

You will still have the option to do the signing and encryption in
two operations. Then the 'encrypted to' packets will not be present
in the signature.

-- 
Terje BrĂ¥ten