Subject: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Mon, 20 May 2002 22:27:03 +0200

Hi

Take a look at:
http://lists.gnupg.org/pipermail/gnupg-devel/2002-May/007159.html

Have you considered what Adrian writes about here in this forum?
I think it is a very good solution to add a 'intended encryption key' or
somthing like that in the section
5.2.3.1. Signature Subpacket Specification.

-- 
Terje Bråten

---

From: "Hal Finney" <[email-masked]>
Date: Mon, 20 May 2002 15:12:26 -0700

There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal

---

From: Terje Braaten <[email-masked]>
Date: Tue, 21 May 2002 16:28:16 +0200

vedaal <[email-masked]> wrote:
> 
> ----- Original Message -----
> From: "Terje Braaten" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.

How can that be? Which functionality in Open PGP are you referring to?
Is it specified anywhere in the RFC?

> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and 
> encrypted message that
> appears the same as a de-novo signed and encrypted message.
> 
> The most that can be done with the separation and 
> re-encryption, is to have
> a message, that upon decryption, is clearsigned,
> or armored signed, and even the armored signed message is clearly of a
> different form than a de novo armored signed message;
> {a de novo armored signed message always has the message 
> block begin with
> the letters 'ow', the separated armored signed
> message never does}.
> 
> Someone receiving a re-encrypted separated signed message, 
> can instantly
> tell upon decryption, that it was an 'intentionally'
> re-encrypted message, and not an original.

If the attacker only an ordinary user, that might be the case.
But if who the message is supposed to be encrypted to is not signed
when the signature is added, it is only a matter of being a good programmer
to fake a "signed & encrypted" message, given the Open PGP standard
as it is today.

We should not rely on security through obscurity.

-- 
Terje Bråten

---

From: Terje Braaten <[email-masked]>
Date: Wed, 22 May 2002 12:31:32 +0200

Jon Callas <[email-masked]> wrote:
> It's important to understand what's in the envelope and what 
> is not in the
> envelope. The ESK is like the address on an envelope. It's not in the
> envelope. It's outside the envelope and is not protected.

That is a good picture of what is the problem. The solution I proposed
is to put a copy of the address(es) on the outside of the envelope also
inside the envelope. If what is on the outside do not match what is on
the inside the user should get a warning that the message is (most probably)
encrypted by some one else than the person that signed the message.

-- 
Terje Bråten

---

From: Terje Braaten <[email-masked]>
Date: Wed, 22 May 2002 16:22:34 +0200

> -----Original Message-----
> From: vedaal [mailto:[email-masked]]
> Sent: 22. mai 2002 15:01
> To: [email-masked]
> Subject: Re: secure sign & encrypt

[...]
> I thought that a packet that simply records the elapsed time 
> in fractions of
> a second, between signing and encrypting,
> could be added without affecting the signature or encryption 
> packets, and
> might be easier to implement without affecting
> backward compatiblity.

If it is not signed (i.e. a signed signature packet) but only added
to the message on the outside, it is nothing that stops the attacker
from just faking that time packet.

> 
> [...]
> 
> > If it is not a signature packet, I do not understand what would
> > keep the attacker from making a fake timestamp when 
> re-encrypting the
> > message.
> 
> It would be an 'record of actual elapsed time' packet,  
> measured from the
> time the program calls for the time of signing,
> to the time it calls for encrypting.  It would not be 'calculated' by
> measuring the recorded (old) timestamp of the signature,
> and then re-setting the attacker's computer to the same time 
> and measuring
> the fractions of seconds till the encryption.

You say "It would not be 'calculated' by ...", but then you rely
on the attacker using a certain program or implementation of OpenPGP.
When designing a security protocol, we must assume that an attacker
will be able to use any program that he likes or even write his own
programs.
If it is permitted by the protocol, the attacker can do it, even
if it is not possible to do it using the usual implementations of the
protocol.

> 
> { i do not yet know how to read and write code :(  , so it is only my
> opinion of what seems plausibly 'do-able' ,
> it may be that it has flaws that experienced programmers can 
> instantly see,
> if so, i apologize in advance}

You are forgiven.

-- 
Terje Bråten

---

From: Terje Braaten <[email-masked]>
Date: Wed, 22 May 2002 18:10:34 +0200

> From: Derek Atkins [mailto:[email-masked]]
> Sent: 22. May 2002 16:09
[...]
> No, the best way around this problem is the USER INTERFACE and
> EDUCATION.  If you receive a signed message that looks like:

I have to disagree with you there Derek. It is not possible to
write an user interface that automatically detects this problem if
there is no support for it in the protocol. It has to be specified
in the protocol that under a sign & encrypt operation the application
MUST make an 'encrypted to' packet in the signature for each key
the message and signature packet is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature (if it is to be a good signature).

No matter how much you try to educate your users, I think that
yet for a few decades most people will think that when they receive
an email that is both signed and encrypted, most will assume that
they can be sure that the signer and the encrypter is the same person.
I think it will be a very great improvement in the protocol to make
it so that it really can be true.

-- 
Terje Bråten

---

From: "Hal Finney" <[email-masked]>
Date: Wed, 22 May 2002 10:09:03 -0700

The problem is that this sign-and-encrypt issue is just the tip of
the iceberg.  It is not worth redoing the protocol when there are these
other issues that will remain unresolved.

First, as mentioned before there is still the chance of confusion if a
clearsigned message is misdirected.  Most people will assume that if they
get an email from someone who PGP signed it, that the email was directed
towards them.  The PGP signature will add weight and authority to this
misconception.  Fixing the sign and encrypt problem won't help with this.

Second, there are other issues than sender/recipient which people
may assume implicitly are being protected by PGP.  This could include
message subject and possibly other header fields.  People will often
assume a certain context in interpreting a message based on this data.
If someone gets an email from their boss with the subject "Smithers
account" and the content tells them to "cancel the account immediately",
the subject line is crucially important in interpreting the message.
PGP does not protect this data, but users may not understand this.

I read the paper and closely followed the extensive discussion on the
cryptography list when this came out last year.  In my opinion the
consensus among the professionals on that list was that, properly
understood, there is more to this than a protocol flaw that can be
easily patched.  It represents a fundamental property of encrypted email.
Some data is protected and some is not.

The real solution is to put the entire email, headers and all, into
the signed envelope, and then for the receiving software to compare
the protected headers with those on the actual message.  This will
detect substition of from/to lines as well as other changes, and will
work for both signed and signed+encrypted messages.

We do have data structures to support this via PGP/MIME and the
Message/rfc822 MIME type.  However actually implementing this
functionality is difficult as it requires close integration with the
email software.  In practice, probably only email software providers
would be in a position to provide this level of functionality.

Hal

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 May 2002 16:09:33 +1200 (NZST)

Derek Atkins <[email-masked]> writes:

>No, the best way around this problem is the USER INTERFACE and EDUCATION.

Jim Schaad posted a good analysis of this a while back.  It's attached below
for people who haven't seen it.

Peter.

-- Snip --

I was hoping that this issue was going to disappear if I ignored it.  I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.

The problem:  I get a message, signed, and I forward it to you signed
and then possibly encrypted.  You believe that since it was encrypted to
you that nobody else could have sent it but the signer.

Response:  1) A better answer is to put names in e-mail.  2) Am I
suppose to start doing this for all signed mail.  3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail.  4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)

Why this does not work:  I don't know how to begin to tell Microsoft how
to write this code.  The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message.  But this is not an easy
thing to say and program in.

1. When I was working at Microsoft, people sent me mail at the address
"[email-masked]", my mailbox name was
"[email-masked]".  There is no way to determine that these
are or are not the same address.  While in this case they were they
could just have easily been different addresses.

2. Today, the email address that I give people is "[email-masked]",
but this is not the mail box address that I use.  This address forwards
mail to a second address where I down-load my mail from.  Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).

3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists.  This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.

4. BCC addressing causes massive problems.  Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient.  (Does the BCC signature still have the list of all non-BCC
recipients?).  The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.

5. What are the correct processing rules to deal with the following
situations:
- Nested signatures:  Does this element in an outer signature remove the
requirement for it to be checked on an inner signature?  Does it add or
change the behavior in some way?
- Parallel signature:  What does this mean for two different
side-by-side signatures, possible with different recipient lists?  If I
am on either list I don't need to display this warning?
- Nested Messages:  What happens if I bodily encapsulate an RFC822
message and forward it to you.  Do you check for the encapsulating but
not the embedded message?  Do you check the embedded message for the
from address of the encapsulating message?

I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.

jim

---

From: Terje Braaten <[email-masked]>
Date: Thu, 23 May 2002 16:08:02 +0200

David P. Kemp <mailto:[email-masked]> wrote: 
> Your proposal for an extra packet does not address this alleged flaw.
> Note that Alice could sign a message saying "encrypted to 
> Bob", and then
> encrypt and send the message to Charlie, thus framing Bob for breach
> of confidence.

No, because then Charlie would know it was something fishy going on.
He would not now if Alice or Bob (or some one else) was to blame,
but he would get a warning message saying that this is an invalid
signed & encrypted message.

> 
> You can't take two operations that are inherently separable and create
> a magic hack that makes them inherently and verifiably atomic.  Each
> layer does what it does - if you want the security services provided
> by three layers (ESE), or what S/MIME calls triple-wrapping (SES),
> then you must use three layers.

Well, if you use three layers (ESE), you get the added bonus that you
can easily see what is wrong if someone try to do something bad.
But also with my proposed method you can verify if everything is ok or not.

-- 
Terje Bråten

---

From: "Dominikus Scherkl" <[email-masked]>
Date: Thu, 23 May 2002 17:40:45 +0200

Hi!

> signed & encrypted message.
Hey, this is an attack at _Bob_ - Charlie don't needs to be nice!
The simple possibility of such attacks discredits the trust in beeing
the original receiver of a message, so we gain nothing!

Best Regards.
-- 
Dominikus Scherkl
[email-masked]

---

From: "Dominikus Scherkl" <[email-masked]>
Date: Thu, 23 May 2002 17:58:11 +0200

Hi.

> > I see no other way than "encrypt, sign and encrypt" (ESE)
> > to archive all cyptografic goals which seems inportant to me:

> The interesting thing is that there is nothing STOPPING an application
> from doing this today.  OpenPGP messages like the following are
> perfectly legal syntax, even in 2440:
> 
> ESK [...] Enc { PreSig ESK [...] Enc { Literal { Message } } PostSig }
> 
> Go ahead and implement this.  I'm fairly sure that most of the OpenPGP
> Parsers out there will Do The Right Thing with this (I'm 99% sure that
> PGP 6.5.x will do this, since I wrote that original parser code).

Of course. That's the main advantage of ESE, we can do it without
protocol changes - to insert a new button in the applications will
be enough.
In addition ESE has the property John Callas repeatedly claimed
to be important, and which can't be archived by simply adding
a copy of the header fields to the envelop:
it ensures that the reciever cannot forward a message
without destroying the signature or reveiling that it was
originaly send to him for his eyes only.
Also ESE can't be cheeted by adding fake addresses to the envelop.

And the old SE remains available, if you like the message can be
forwarded but therefore repudiated.

Best Regards

---

From: Terje Braaten <[email-masked]>
Date: Thu, 23 May 2002 18:20:47 +0200

> the original receiver of a message, so we gain nothing!

The only one that could mount such an attack is Alice, the
person that has signed the message. So such an attack would be easily
traceable. The trust in who is the original receiver of a message
will depend on that you trust the signer if test to see if
the signer and encrypter is the same person is false.
Yes, that makes this method a bit weaker than ESE. When the test
fails you cannot infer anything about who was the real recipient.
But if the test to see if the signer and encrypter is the same person
returns true, then you can indeed be sure that the signer and
encrypter is the same person.

-- 
Terje Bråten

---

From: Terje Braaten <[email-masked]>
Date: Thu, 23 May 2002 22:34:10 +0200

Derek Atkins <[email-masked]> writes:
> 
> Terje Braaten <[email-masked]> writes:
> 
> > Derek Atkins <[email-masked]> wrote:
> > > I'm not sure exactly what you mean by when you say Alice 
> saves a copy
> > > of the session key... How does Alice get that key to 
> Charlie?  Also
> > > keep in mind that the interior and exterior encryptions SHOULD be
> > > using different session keys.  So, I don't understand 
> what you mean?
> > 
> > She could send it to Charlie in a different mail, or add it 
> on the outside
> > of the signature (ES) packet before she encrypt and send it 
> to Charlie.
> > And since she control the building of the message, another solution
> > would be that she could also use the same session key in 
> the interior and
> > exterior encryptions no matter what the protocol says 
> should be done.
> 
> But then Charlie KNOWS that Alice did the dastardly deed.  Moreover,
> you'd need extremely special reader to be able to read such a message,
> because it would not be 2440-compliant.

No, if Alice faked the e-mail headers, he could think it was Bob that
sent it to him, and also revealed to him the session key to the inner
encryption packet. It is exactly the same case as if Alice just had
used SE and signed a packet with the recipient keys in the inner message.
Charlie would KNOW that something was wrong, but not if Alice or Bob
was to blame.

> 
> > > Can you show the packets that Charlie sees?  I don't see any way
> > > to add a new ESK on the interior message without invalidating the
> > > signature....
> > 
> > Charlie sees after decrypting the first layer
> >  PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]
> 
> Ok, can you show me the complete message Charlie receives (before he
> decrypts the first layer)?  Note that if Charlie sees this message, it
> is quite clear that the message was meant for Bob alone.

Yes, but was it Bob that leaked the information or Alice? See he cannot
know.

> 
> > In addition he has, or can make ESK[Charlie]. This 
> information he can
> > claim he must have got from Bob, since he is the only 
> original recipient.
> 
> How can Charlie insert an ESK[Charlie] and not invalidate the
> signature?

He cannot insert it in the inner encryption packet without invalidating
the signature, but he can make use of it to read the encrypted message.

-- 
Terje Bråten

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 24 May 2002 16:58:06 +1200 (NZST)

"David P. Kemp" <[email-masked]> writes:

>Each layer does what it does - if you want the security services provided by
>three layers (ESE), or what S/MIME calls triple-wrapping (SES), then you must
>use three layers.

The motivation for S/MIME triple wrap was AFAIK use by automated mail gateways.
If you always have to sign the plaintext then it makes it impossible to create
a mail gateway which only lets signed data in or out, because the gateway would
have to hold all the private keys in order to verify the sigs.  Thus the SES
triple-wrap.  I know Don Davis looked at the RFC which covered this (2633?)
when he was writing his paper and found it didn't really solve the problem.

Peter.