crypto flaw in secure mail standards

[Don Davis]

All current secure-mail standards specify, as their "high-
security" option, a weak use of the public-key sign and encrypt
operations.  On Thursday the 28th of this month, I'll present
my findings and my proposed repairs of the protocols, at the
Usenix Technical Conference here in Boston:
  http://www.usenix.org/events/usenix01/usenix01.pdf

Citation:
Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS,
PEM, PGP, and XML."  To appear in Proc. Usenix Tech. Conf. 2001,
Boston.  June 25-30, 2001.

A short summary:  All current secure-mail standards have a
significant cryptographic flaw.  There are several standard
ways to send and read secure e-mail.  The most well-known
secure mail systems are PGP and S/MIME.  All current public-
key-based secure-mail standards have this flaw.  Here are some
examples of the flaw in action:

Suppose Alice and Bob are business partners, and are setting
up a deal together.  Suppose Alice decides to call off the
deal, so she sends Bob a secure-mail message: "The deal is off."
Then Bob can get even with Alice:

  * Bob waits until Alice has a new deal in the works
with Charlle;
  * Bob can abuse the secure e-mail protocol to re-encrypt
and resend Alice's message to Charlie;
  * When Charlie receives Alice's message, he'll believe
that the mail-security features guarantee that Alice
sent the message to Charlie.
  * Charlie abandons his deal with Alice.

Suppose instead that Alice & Bob are coworkers.  Alice uses
secure e-mail to send Bob her sensitive company-internal
sales plan.  Bob decides to get his rival Alice fired:

  * Bob abuses the secure e-mail protocol to re-encrypt and
resend Alice's sales-plan, with her digital signature,
to a rival company's salesman Charlie.
  * Charlie brags openly about getting the sales plan from
Alice.  When he's accused in court of stealing the plan,
Charlie presents Alice's secure e-mail as evidence of
his innocence.

Surprisingly, standards-compliant secure-mail clients will
not detect these attacks.

--
Abstract
   Simple Sign & Encrypt, by itself, is not very secure.
Cryptographers know this well, but application programmers
and standards authors still tend to put too much trust
in simple Sign-and-Encrypt.  In fact, every secure e-mail
protocol, old and new, has codified naïve Sign & Encrypt
as acceptable security practice.  S/MIME, PKCS#7, PGP,
OpenPGP, PEM, and MOSS all suffer from this flaw.
Similarly, the secure document protocols PKCS#7, XML-
Signature, and XML-Encryption suffer from the same flaw.
Naïve Sign & Encrypt appears only in file-security and
mail-security applications, but this narrow scope is
becoming more important to the rapidly-growing class
of commercial users. With file- and mail-encryption
seeing widespread use, and with flawed encryption in
play,  we can expect widespread exposures.

In this paper, we analyze the naïve Sign & Encrypt flaw,
we review the defective sign/encrypt standards, and we
describe a comprehensive set of simple repairs.  The
various repairs all have a common feature:  when signing
and encryption are combined, the inner crypto layer must
somehow depend on the outer layer, so as to reveal any
tampering with the outer layer.



Once I've presented the paper, I'll make this link live:
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps

- don davis, boston
  http://world.std.com/~dtd





-






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

crypto flaw in secure mail standards

[Don Davis]

> All current secure-mail standards specify, as their
> "high-security" option, a weak use of the public-key
> sign and encrypt operations. ...

i've received permission from usenix to release the
paper on saturday (6/23):

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

- don davis, boston
  http://world.std.com/~dtd





-





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Derek Atkins]

This is not a crypto flaw.  This is an engineering flaw.

First, the timestamp of the message is certainly encoded in the
signature.  This is protection against your first suggested attack.
The recipient, upon verifying the signature, notices that it was made,
e.g., two months previously.  Then one would have to wonder why a
two-month-old message was being sent.

The other obvious problem is that although the sender's identity is
encoded in the message's signature (as well as the time the signature
is purported to be made), the original intended recipient's are not
encoded within the signed portion of the message.  The simple fix
would be to include the appropriate mail headers withing the signed
portion of the message.  In particular, including the 'To' and 'Cc'
fields would immediately protect against both of these attacks.

The problem is not at all with the crypto.  The problem is with the
integration of the crypto with applications like e-mail.

Have a nice day,

-derek

Don Davis <[EMAIL PROTECTED]> writes:

> All current secure-mail standards specify, as their "high-
> security" option, a weak use of the public-key sign and encrypt
> operations.  On Thursday the 28th of this month, I'll present
> my findings and my proposed repairs of the protocols, at the
> Usenix Technical Conference here in Boston:
>   http://www.usenix.org/events/usenix01/usenix01.pdf
> 
> Citation:
> Don Davis, "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS,
> PEM, PGP, and XML."  To appear in Proc. Usenix Tech. Conf. 2001,
> Boston.  June 25-30, 2001.
> 
> A short summary:  All current secure-mail standards have a
> significant cryptographic flaw.  There are several standard
> ways to send and read secure e-mail.  The most well-known
> secure mail systems are PGP and S/MIME.  All current public-
> key-based secure-mail standards have this flaw.  Here are some
> examples of the flaw in action:
> 
> Suppose Alice and Bob are business partners, and are setting
> up a deal together.  Suppose Alice decides to call off the
> deal, so she sends Bob a secure-mail message: "The deal is off."
> Then Bob can get even with Alice:
> 
>   * Bob waits until Alice has a new deal in the works
> with Charlle;
>   * Bob can abuse the secure e-mail protocol to re-encrypt
> and resend Alice's message to Charlie;
>   * When Charlie receives Alice's message, he'll believe
> that the mail-security features guarantee that Alice
> sent the message to Charlie.
>   * Charlie abandons his deal with Alice.
> 
> Suppose instead that Alice & Bob are coworkers.  Alice uses
> secure e-mail to send Bob her sensitive company-internal
> sales plan.  Bob decides to get his rival Alice fired:
> 
>   * Bob abuses the secure e-mail protocol to re-encrypt and
> resend Alice's sales-plan, with her digital signature,
> to a rival company's salesman Charlie.
>   * Charlie brags openly about getting the sales plan from
> Alice.  When he's accused in court of stealing the plan,
> Charlie presents Alice's secure e-mail as evidence of
> his innocence.
> 
> Surprisingly, standards-compliant secure-mail clients will
> not detect these attacks.
> 
> --
> Abstract
>Simple Sign & Encrypt, by itself, is not very secure.
> Cryptographers know this well, but application programmers
> and standards authors still tend to put too much trust
> in simple Sign-and-Encrypt.  In fact, every secure e-mail
> protocol, old and new, has codified na=EFve Sign & Encrypt
> as acceptable security practice.  S/MIME, PKCS#7, PGP,
> OpenPGP, PEM, and MOSS all suffer from this flaw.
> Similarly, the secure document protocols PKCS#7, XML-
> Signature, and XML-Encryption suffer from the same flaw.
> Na=EFve Sign & Encrypt appears only in file-security and
> mail-security applications, but this narrow scope is
> becoming more important to the rapidly-growing class
> of commercial users. With file- and mail-encryption
> seeing widespread use, and with flawed encryption in
> play,  we can expect widespread exposures.
> 
> In this paper, we analyze the na=EFve Sign & Encrypt flaw,
> we review the defective sign/encrypt standards, and we
> describe a comprehensive set of simple repairs.  The
> various repairs all have a common feature:  when signing
> and encryption are combined, the inner crypto layer must
> somehow depend on the outer layer, so as to reveal any
> tampering with the outer layer.
> 
> 
> 
> Once I've presented the paper, I'll make this link live:
> http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps
> 
>   - don davis, boston
> http://world.std.com/~dtd
> 
> 
> 
> 
> 
> -
> 
> 
> 
> 
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

-- 
   Derek Atkins, SB '93 MIT EE, 

Re: crypto flaw in secure mail standards

[lcs Mixmaster Remailer]

Don Davis writes,

> All current secure-mail standards have a
> significant cryptographic flaw.  There are several standard
> ways to send and read secure e-mail.  The most well-known
> secure mail systems are PGP and S/MIME.  All current public-
> key-based secure-mail standards have this flaw.  Here are some
> examples of the flaw in action:
>
> Suppose Alice and Bob are business partners, and are setting
> up a deal together.  Suppose Alice decides to call off the
> deal, so she sends Bob a secure-mail message: "The deal is off."

The only thing protected in a signed message is that portion signed.
Alice needs to say, "Bob, the deal is off."

Actually this is not enough.  Suppose Alice sends this, or equivalently
suppose we use an encryption scheme similar to what David Hopwood
describes where the inner signed portion includes the outer key.

There can still be trouble.  Suppose at some later time Alice and Bob
negotiate a new contract, and Bob wants to get out of it.  He pulls out
this old message of Alice's and stamps a new date on it, claiming that
it was with regard to their new contract negotiation.  He says that
Alice withdrew from the contract so he is not liable for any penalties.

Again the problem is that only what is signed is protected.  If the date
is not signed, it is not protected.  So the protocol has to include the
date in the signature.  (Actually I think most email encryption protocols
do this, but the point is that the formal description of what is signed
may not show that.)  Only what is signed is protected.

Even the date may not be enough.  Suppose Alice and Bob are separately
negotiating two different contracts, using a threaded mail reader
which uses Reply-To: or some similar fields in the mail header so
that exchanges with regard to one contract are shown separately from
exchanges with regard to the other.  Then Alice might send, "Bob, the
deal is off," including a date in the signature, and expect it to apply
just to the deal being negotiated in that thread, because that's how her
mail software shows it.  However Bob can take the message and claim that
it applied to the other thread.

In this case, other context that was in the minds of Alice and Bob is
not being covered by the signature.  This is really the general form of
the issue being discussed.  What is in the minds of the participants,
what assumptions are they making that are not being written down?

This is why we have lawyers and contracts and fine print.  These
institutions and practices are the result of centuries of people weaseling
out of contracts in various ways.

It is mistaken to think that we can solve this problem by a little
cryptographic legerdemain involving copying a field from the outer
encryption envelope into the inner signature.  That does not begin to
cover all of the things that can go wrong.

The only real solution is to use the advice and experience of the
legal system when negotiating a contract which will bind the parties.
Make sure everything is written down and sign a document which is as
clear, specific and free of ambiguity as possible.

It's not a cryptographic issue, and failures of this kind are not
cryptographic failures.  Cryptography can't read the minds of the
parties involved and know that all of their assumptions are included in
the signed portion.  The real solution is for the communicants to take
the responsibility to put everything there that is needed.  Only what
is signed is protected.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Jeffrey I. Schiller]

In fact there are many applications where the separation of the
signing operation from the encryption operation are useful and
important.

Encryption provides a different service then the underlying
signature. It protects the document from being read by unintended
recipients. The signature can provide proof later that the sender did
in fact sign the message.

It is always the case that one must be careful what one writes in
e-mail, for once delivered to the recipient, the sender looses control
of the document.  In fact this threat even exists in paper mail. If
Alice sends Bob a "The deal is off" letter, but doesn't mark the
letter with enough context, Bob can always physically forward the
letter to a third party and claim it is from Alice.

I believe it is important that message signatures outlive the
message's encryption layer. If I receive a signed/encrypted message. I
will loose the ability to decrypt it if I loose my private key (or
intentionally destroy it to prevent its future compromise). However if
I remove the encryption and store the message signed (perhaps
protected by other mechanisms in my mail store), I can always verify
the signature as long as I have access to the sender's certificate
chain. No secrets have to be saved.

Btw. I don't believe S/MIME has timestamps in its signature
format. PGP does. PGP also implements a "for her eyes only" feature
that only permits an encrypted message to be displayed, but not saved
in a file. Now of course a sufficiently clever person can circumvent
this protection. I am now wondering how hard it would be to circumvent
this feature *and* keep the original message signature (of course if
you have the PGP source code, you can do this).

However, having said all this, Don has a point. There may be a class
of message where you want to prove that you originated it *only to the
original sender*.  If he has a way to do that, it sounds like a good
thing.

But there isn't a flaw in secure e-mail, just a missing service.

-Jeff



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Bram Cohen]

On Fri, 22 Jun 2001, Jeffrey I. Schiller wrote:

> I believe it is important that message signatures outlive the
> message's encryption layer.

Currently, if you are compromised at some point then an attacker can go
back to the mail archives and read every message you've ever sent or
received. With separate encryption keys, it would be possible to achieve
forward secrecy, so that the old messages would be unreadable to everyone,
including you.

Forward secrecy is arguably a more important property of mail to have than
authentication, and is much easier to build properly, since it doesn't get
into the issues of identity. Unfortunately, none of the current mail
standards support it at all.

In fact, forward secrecy is all that Disappearing Inc. did - does anybody
know how they're doing?

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Radia Perlman - Boston Center for Networking]

From: "Jeffrey I. Schiller" <[EMAIL PROTECTED]>
>> There may be a class
>> of message where you want to prove that you originated it *only to the
>> original sender*.  If he has a way to do that, it sounds like a good
>> thing.

Actually I don't think Don was talking about that. Instead he was
talking about the danger of leaving things out of the
signature like the subject
line, the to field, the date, etc., that would allow someone to
take Alice's message out of context, and other people on the list
have explained that you need to have all stuff that matters be
covered by the signature, perhaps by having the user consciously
know what matters and include it in the body.

But what Jeff suggested as a feature in
his email is interesting, and Charlie and I worked
that out in our book when we were discussing how to do what we
called "plausible deniability" with public keys, and non-repudiation
with secret keys, since obviously the opposite is straightforward.
What Jeff is asking about is doing plausible deniability with public
keys, i.e., Bob knows the message came from Alice but he can't prove
it to anyone else.

And the way we specified for Alice to send a "signed only to Bob" message
to Bob is for her to pick a secret key S that she'll only
use for this message, encrypt S with Bob's public key (i.e., {S}Bob),
sign the result (i.e., [{S}Bob]Alice), and compute a MAC on the message using S.
Bob can't prove to anyone else that Alice sent it, since he could construct
any message he wants using a MAC(msg, S). All he can prove is that
at some point Alice sent him something that used S. But he knows it
came from Alice.

Radia




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ben Laurie]

"Jeffrey I. Schiller" wrote:
> Btw. I don't believe S/MIME has timestamps in its signature
> format. PGP does. PGP also implements a "for her eyes only" feature
> that only permits an encrypted message to be displayed, but not saved
> in a file. Now of course a sufficiently clever person can circumvent
> this protection. I am now wondering how hard it would be to circumvent
> this feature *and* keep the original message signature (of course if
> you have the PGP source code, you can do this).

Ummm ... and who would we expect _not_ to have the source?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

In Boston 'til 1st July.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[lcs Mixmaster Remailer]

Derek Atkins writes:
> The other obvious problem is that although the sender's identity is
> encoded in the message's signature (as well as the time the signature
> is purported to be made), the original intended recipient's are not
> encoded within the signed portion of the message.  The simple fix
> would be to include the appropriate mail headers withing the signed
> portion of the message.  In particular, including the 'To' and 'Cc'
> fields would immediately protect against both of these attacks.

That's right, and maybe some other mail headers ought to be included too.
We've all seen messages where the Subject header determines the context
of the message.  Imagine that Alice sends a message with "Subject: Milk
spoils if left out too long" and the body says, "... and I've seen it
happen, too."  Then she sends that signed, and some mischievous person
changes it to "Subject: The boss wears women's underwear" and we have
a signed message from Alice saying "... and I've seen it happen, too."
Poor Alice, she can't catch a break.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[James M Galvin]

On Fri, 22 Jun 2001, Jeffrey I. Schiller wrote:

But there isn't a flaw in secure e-mail, just a missing service.

To put it another way, Don has identified the difference in what
non-repudiation frequently means to an engineer/technologist and what it
means to a lawyer/business.  The missing element is "timeliness".

Public key cryptography, or naive signing as Don was calling it, does
not in and of itself solve the non-repudiation problem.  It is certainly
an assertion as to the origin of whatever is signed but it asserts
nothing regarding the context of whatever is signed, of which timeliness
is essential.

I'd have to go back and look to be sure but it seems to me we got this
distinction right in our email standards; we were careful to state that
the signature identifies the origin of the message and that is all.

That hardly makes our secure email protocols *flawed*, although perhaps
they are easy to use incorrectly.  On the other hand, they all talk
about the object to be signed, which could just as easily be the entire
original message instead of just its content, which assuming suitable
To:, Cc:, Date:, and Subject: headers would solve the issue at hand.

Jim





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Bram Cohen]

The problem here is that all the encrypted mail standards don't actually
send encrypted mail, they send encrypted files in mail. A *mail* message
consists of headers and a body. The right way to send encrypted mail is to
create a mail message, encrypt it headers and all, and include that in a
mail message of type multipart/alternative, with the alternative being a
text message saying 'this mail is encrypted'.

The sticky point is the Message-id header, which is generally tacked on by
the server. There are a couple ways it could be dealt with.

I recently did some digging into encrypted mail standards and was appalled
that they don't work that way. Reinventing how mail works is not something
one should do while giving it encryption. I raised a big stink about it on
coderpunks and said I'd make my own standard for encrypted mail before I'd
implement any of the existing ones, which I got a bunch of criticism
for. I didn't realize at the time that the existing ones are insecure in
addition to being stupid.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Derek Atkins]

This works fine in a peer-to-peer scenario, but not if you have a
one-to-many transmission.  Just because you have a message signed in
the set {Alice,Bob,Charlie,Daniel,Eve,Fred,Greg}, there is no way to
know which of them sent it.  All members of the set must be mutually
trusted, which means there is no way to sign a document that a set of
people can verify comes EXACTLY from you.

-derek

dmolnar <[EMAIL PROTECTED]> writes:

> So Alice signs document D as being from the set {Alice, Bob} and sends it
> to Bob. Now Bob knows he didn't write D, so he believes it's from Alice.
> If he passes D along to Charlene, she can't determine whether Alice
> wrote D or Bob came up with it himself.
> 
> In fact, IIRC, the paper suggests the sorts of scenarios discussed in this
> thread explicitly as the motivation for this use of ring signatures. The
> paper then goes on to argue for the practicality of implementing ring sigs
> in mail clients.
> 
> -David
> 

-- 
   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 PROTECTED]PGP key available



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[dmolnar]

On Fri, 22 Jun 2001, Jeffrey I. Schiller wrote:

> However, having said all this, Don has a point. There may be a class
> of message where you want to prove that you originated it *only to the
> original sender*.  If he has a way to do that, it sounds like a good
> thing.

One way to do this is called a "designated verifier signature,"
originally AFAIK discussed by Jakobsson, Impagliazzo, and Sako. Rivest
has a paper up on his web page right now giving a particularly nice way of
implementing it by means of "ring signatures." In a ring signature, you
can determine that the message was signed by a member of a set S, but
not who exactly that member is.

So Alice signs document D as being from the set {Alice, Bob} and sends it
to Bob. Now Bob knows he didn't write D, so he believes it's from Alice.
If he passes D along to Charlene, she can't determine whether Alice
wrote D or Bob came up with it himself.

In fact, IIRC, the paper suggests the sorts of scenarios discussed in this
thread explicitly as the motivation for this use of ring signatures. The
paper then goes on to argue for the practicality of implementing ring sigs
in mail clients.

-David




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Jon Callas]

This is a really good issue you've brought up, brilliant and creative.
However, like Derek said, this isn't a crypto problem. I'm going to go
further and say that it isn't even an engineering problem.

You demonstrate some interesting problems with secure messaging, but *none*
of them have anything to do with cryptography. They all have to do with
semantics, expectation, and human behavior.

Both of the scenarios you give are perfectly plausible. They could happen.
However, they don't *have* to happen that way and presume certain
conditions that are at best specialized.

Let's take the first one. This one presupposes that Alice's signed message
says, "The Deal is off." Note that if Alice had said a number of other
things, there would be no problem.

Suppose Alice's message to Bob is: "Dear, Bob, I'm sorry to send you some
bad news, but my company has had a reorganization, and we cannot pursue our
deal with XYZcorp at this time. I enjoy working with you, and hope that we
will be able to re-activate this deal at a future date."

Now there's no attack. If Bob sends *this* message to Charlie, then
Charlie's going to scratch his head and call Alice by phone. Then they'll
check the email headers, and see that it came from a hijacked IIS server in
Elbonia.

The real problem here is that there are some terse messages that it's a
very bad idea to sign. For example, "The deal's off." Also, "Your mother
wears army boots," "So's your old man," and "Take a long walk off a short
pier."

Cryptography cannot solve the problem of appropriate use of the technology.
Let me give a related "attack." Suppose before she cancels the deal Alice
sends Bob a message that says, "I'm really glad I'm working with you and
not Charlie. He's a real twit, and I have to grit my teeth every time I
deal with him." After canceling the deal, Bob then sends *that* message
with Alice's signature to Charlie. Cryptography can't solve *that* problem,
either. My dear, late friend, Marin Minow had a maxim, and that maxim is,
"Don't send anything by email that you don't want to see attached to your
resume." That can be extended to really, really, not sending a signed
document that you don't want to see attached to your resume.

I will also point our here, that the attack you give needs no encryption.
This is why I say it isn't even an engineering problem. It works equally
well with a clearsigned message. Adding in encryption weakens your case.
It's a more powerful attack on signing alone because anyone who finds that
message can retarget it.

My response, simply put, is don't sign a vague message like this:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The deal's off

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.2

iQA/AwUBOzOb9HwuAgBhK7KNEQLRSwCeMNxIiaf04ZejMbkmcxjhTX7R/10AoJKs
LbL3yWM4BrjmfvOYCGIdl0YG
=h7ZQ
-END PGP SIGNATURE-

because you'll be subject to retargeting. There is nothing a cryptographer
or engineer can do to protect such an easily misunderstood message.

The next problem you give is more interesting. It's again, misuse rather a
crypto problem, but it strikes at the heart of two unsolved issues with
digital signatures:

(1) What does a signature mean?
(2) Can a signature be misused?

The answers to those questions are in my opinion, "Whatever you want them
to" and "Yes." Again, your demonstrations are brilliant examples of how you
can misuse a signature into some sort of semantic attack.

The first question is a swamp, so I'll only dance around it. I know people
who regularly sign all their email. I know people who refuse to sign email
(or rarely do). Each of them has a good explanation for why they do what
they do. For full disclosure, I rarely sign messages. Since I rarely sign
messages, it's relatively easy for someone to forge one coming from me. On
the other hand, since I don't sign messages out of habit, I'm not going to
accidentally create a retargetable message. But what this shows is that if
you find a signed document in the wrong hands, the assumption that the
signer sent it is flat silly.

The second question strikes at the very heart of one of the biggest
fantasies there is with digital signatures: non-repudiation. I don't
believe that non-repudiation exists. This second example is not an attack
on cryptography, but a brilliant attack on the notion of non-repudiation.
Stan Kelley-Bootle has a marvelous definition in "The Devil's DP
Dictionary" for "GIGO" that is, "Garbage In, Gospel Out." Sheer brain-dead
fantasies having been run through a computer become holy and divinely
inspired. Similarly, people think that a digital signature makes real-world
considerations go away, and alas, the people who believe this most are
lawyers (who should know better).

Let's analyze that second problem. Someone goes to Alice and says, "Hey,
Charlie has a catalog signed by you." Alice says, "Who's Charlie? I've
never heard of Charlie. I've never sent sensitive company material outside
the company." We all know tha

Re: crypto flaw in secure mail standards

[Jeffrey I. Schiller]

On Fri, Jun 22, 2001 at 06:23:46PM -0400, Radia Perlman - Boston Center for Networking 
wrote:
> Actually I don't think Don was talking about that. Instead he was
> talking about the danger of leaving things out of the
> signature like the subject
> line, the to field, the date, etc., that would allow someone to
> take Alice's message out of context, and other people on the list
> have explained that you need to have all stuff that matters be
> covered by the signature, perhaps by having the user consciously
> know what matters and include it in the body.

Ah. This is why I always replicate the Subject field (and other important)
fields in message that I sign for posterity (such as IESG action requests).

-Jeff



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Peter Gutmann]

"Jeffrey I. Schiller" <[EMAIL PROTECTED]> writes:

>I don't believe S/MIME has timestamps in its signature format.

It's a standard part of the S/MIME signature.  Optional features include
countersignatures from external timestamping authorities.

Peter.




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Don Davis]

At 10:15 AM -0500 6/22/01, Don Davis wrote:
> All current secure-mail standards specify, as their
> "high-security" option, a weak use of the public-key
> sign and encrypt operations.

please forgive my failure to reply to the list
members' comments individually, but my paper has
attracted so much mail, that i can't fulfill my
obligation to answer each of you courteously.

your critiques fall into a few categories:

   * old news; there's no new crypto problem here;
   * not a crypto problem, but a foolish-user problem;
   * not a crypto problem; the attacks work even
 without encryption, and even with surface mail;
   * not a crypto problem, because the problem is
 easily fixed with signed header-info, or with
 signed salutations.
   * this problem is one of a large class that's
 too hard to fix in full generality.

my paper raises almost all of these points, and i
agree with all of them, except with their common
theme: "it's not really a crypto problem."  in my
paper, i argue that there _is_ a clear-cut lapse of
good crypto-protocol design here.  the most basic
difference between my claim and the critiques, is
about usability.  i believe today's secure-mail
protocols should fulfill today's users' rather
naïve and inarticulate expectations about security
and ease-of-use.  unfortunately, today's secure-mail
protocols were designed before these naïve newbie
users flooded into the net.  this isn't the fault
of the diligent and brilliant engineers who contri-
buted to the various secure-mail standards.  but,
i suggest that it's more realistic to revisit their
work, and to change the secure-mail protocols and
products, than it is to try to change all of the
net's naïve users into crypto-aware users who can
wield the current secure-mail products effectively.

- don davis, boston






-






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Eric Rescorla]

Radia Perlman - Boston Center for Networking <[EMAIL PROTECTED]> writes:
> But what Jeff suggested as a feature in
> his email is interesting, and Charlie and I worked
> that out in our book when we were discussing how to do what we
> called "plausible deniability" with public keys, and non-repudiation
> with secret keys, since obviously the opposite is straightforward.
> What Jeff is asking about is doing plausible deniability with public
> keys, i.e., Bob knows the message came from Alice but he can't prove
> it to anyone else.
This sounds to me like what's usually called "data origin authentication".

> And the way we specified for Alice to send a "signed only to Bob" message
> to Bob is for her to pick a secret key S that she'll only
> use for this message, encrypt S with Bob's public key (i.e., {S}Bob),
> sign the result (i.e., [{S}Bob]Alice), and compute a MAC on the message using S.
> Bob can't prove to anyone else that Alice sent it, since he could construct
> any message he wants using a MAC(msg, S). All he can prove is that
> at some point Alice sent him something that used S. But he knows it
> came from Alice.
That's one way to do it. Of course, if you're using Diffie-Hellman
keys then there's a far easier approach. You simply generate a MAC key
from the DH shared secret and use that the compute a MAC over the
message. Note that it's perfectly straightforward to have a key
expansion transform which generates both a MAC key and an encryption
key so that you only need to do one DH exchange.

Of course, this requires that the sender has a static DH key--watch
out for small subgroup attacks :)

-Ekr

[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Enzo Michelangeli]

A question for legal experts on the list: Does all this pose legal risks
within the current legal framework? In other word, do current digital
signature laws assume that also the headers are assumed to be authenticated
and non-repudiable if the message is digitally signed?

Enzo

- Original Message -
From: "lcs Mixmaster Remailer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 23, 2001 5:40 AM
Subject: Re: crypto flaw in secure mail standards


> Derek Atkins writes:
> > The other obvious problem is that although the sender's identity is
> > encoded in the message's signature (as well as the time the signature
> > is purported to be made), the original intended recipient's are not
> > encoded within the signed portion of the message.  The simple fix
> > would be to include the appropriate mail headers withing the signed
> > portion of the message.  In particular, including the 'To' and 'Cc'
> > fields would immediately protect against both of these attacks.
>
> That's right, and maybe some other mail headers ought to be included too.
> We've all seen messages where the Subject header determines the context
> of the message.  Imagine that Alice sends a message with "Subject: Milk
> spoils if left out too long" and the body says, "... and I've seen it
> happen, too."  Then she sends that signed, and some mischievous person
> changes it to "Subject: The boss wears women's underwear" and we have
> a signed message from Alice saying "... and I've seen it happen, too."
> Poor Alice, she can't catch a break.
>
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Greg Broiles]

At 09:45 AM 6/24/2001 +0800, Enzo Michelangeli wrote:

>A question for legal experts on the list: Does all this pose legal risks
>within the current legal framework? In other word, do current digital
>signature laws assume that also the headers are assumed to be authenticated
>and non-repudiable if the message is digitally signed?

The digital signature laws I've seen don't mention and don't support the 
notion of "non-repudiation", which seems to be an obsession among computer 
security people and a non-issue among legal people. The idea that something 
is "non-repudiable" or unarguable or unavoidable is nonsense. I use it as a 
clue detector - if someone talks about non-repudiation, they don't know 
much about US contract law.

The attack raised - at least as it's been summarized, I haven't gotten 
around to the paper yet - sounds like a good one to remember, but too 
contrived to be especially dangerous in the real world today. How often do 
you, or people you know, send short context-free messages to conclude 
important negotiations? And how often would you rely on a digital signature 
to assure you that everything was kosher if an otherwise promising deal or 
negotiation suddenly turned bad? And if you thought you had grounds for a 
lawsuit, wouldn't you send a message or make a phone call first, to the 
effect of "I was really surprised that you ended our discussion so 
abruptly. I understood our agreement to require you to continue to supply 
me with widgets for the next 3 years. If you're serious about ending our 
relationship early, I'm going to have to talk to my lawyer about that, 
because you've put me at a serious disadvantage, now that the spot price of 
widgets has gone up so much."

Sure, let's work on this and make systems better, so that signatures 
include context which helps prevent misunderstanding or active attack. But 
the sky isn't falling - this attack is a nuisance, becuase it makes its 
victims spend a few hours on the phone ironing out a misunderstanding - and 
it's not at all likely to lead to serious lawsuits.

I just ran across Jon Callas' earlier message in this thread and think he's 
right on the money. Don't sign tiny no-context messages. Don't get 
distracted by the cartoonish fantasy of non-repudiation.


--
Greg Broiles
[EMAIL PROTECTED]
"Organized crime is the price we pay for organization." -- Raymond Chandler




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[P.J. Ponder]

The laws I have seen are not specific enough to deal with what gets
included in a digitally signed message.  These laws define 'digital
signature' and in some cases invoke so-called trusted third parties to
issues certs, etc., but I haven't seen a law yet with the level of
detail that would require date/time, subject, to, from, etc., in a mail
message.  Most of the laws define something as being digitally signed in
general terms of public key crypto, as for example the Florida (US) law:
|
| (3)  "Digital signature" means a type of electronic signature that
| transforms a message using an asymmetric cryptosystem such that a person
| having the initial message and the signer's public key can accurately
| determine:
|
| (a)  Whether the transformation was created using the private key that
| corresponds to the signer's public key.
|
| (b)  Whether the initial message has been altered since the
| transformation was made.
|
(from section 668.003, Florida Statutes)

As others have pointed out, 'non-repudiation' is not a legal concept.

As a practical matter, if one were potentially damaged by an attack of
this type, one could argue that such a message could be resent, absent the
original context.  This could be demonstrated, experts could testify, etc.

It appears to be a problem in the protocols, but I don't see it as being a
legal problem, esp. in light of the fact that there is no such thing as
'non-repudiation' in the real world.

Seems like another good reason to use a time-stamper like the one at:

http://www.itconsult.co.uk/stamper/

--
pjp

On Sun, 24 Jun 2001, Enzo Michelangeli wrote:

> A question for legal experts on the list: Does all this pose legal risks
> within the current legal framework? In other word, do current digital
> signature laws assume that also the headers are assumed to be authenticated
> and non-repudiable if the message is digitally signed?
>
> Enzo




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[lcs Mixmaster Remailer]

David Wagner wrote (on sci.crypt):

> Can you help me understand this?  Obviously I must be missing something.
> Why do you need to know whether you are going to encrypt?  In particular,
> one obvious proposal would be the following: When you sign, include any
> relevant contextual information (e.g., date, time, To:) in the signature.
> Does this not work?

I agree that something like this is the best solution.  In particular it
is much better than what was actually proposed in the paper, which was
to put the encryption key into the signature, or the signature key into
the encrypt, or to sign or encrypt twice.  Those solutions advance the
illusion that this is a cryptographic problem related to sign+encrypt,
when it is not.  (Others have observed that the same kinds of problems
arise even if the message is not encrypted at all.)  It is a confusion
about what is protected specifically in an email environment, or perhaps
it is a failure to protect some information that could or should be
protected.  More on this below.

Adding To:, etc. to the signature is the best solution in an email
environment.  As other discussions have noted, there are other fields
which could be important as well, such as Subject, Keywords, References,
In-Reply-To, etc..  In fact some have proposed that the entire set of
email headers should be protected by the signature.  This produces the
least ambiguity and possibility of error.

One cost in the context of this solution is that on the sending side the
software may have to be restructured somewhat.  Presently it is likely
that signature and encryption are done before the message is formatted
for transmission.  Many of the mail headers may be stamped on only at
that last point.  The software may have to be rearranged to make sure
that everything is available at an earlier point in the processing.
Granted, this is more of a problem in the context of retrofitting an
existing system.  It might be argued that this problem should have been
recognized from the beginning and secure email been designed to protect
the mail headers all along.

The other cost happens on the receiving side: what to do when the
protected headers don't match the outer ones?  Is this worth raising a
red flag over?  Or perhaps should the inner ones silently overwrite the
outer ones?

It might be that a certain amount of mismatch commonly occurs.
Mail headers are far from sacrosanct, and gateways, mail exploders and
forwarders do sometimes rewrite them.  If we raise a red flag every time
then people will learn to just ignore the warnings.  If we silently
overwrite then we might lose some of the advantages of the rewriting
which is done (for example mailing lists sometimes rewrite Subject to
tag it with the name of the list, to move a "Re" past the list name, etc.)

These issues can probably be solved but they require some thought and
care in implementing this proposed new capability.

> P.S. Regarding the example about the court: That's not the example I find
> most compelling, because in a court case there are enough resources that
> the potential for such a the failure mode would perhaps be discovered.
> Rather, I'm most worried about everyday users being confused by such an
> attack, where there is no issue about taking things to court.

Okay, but again, we are talking about confusion here.  The real problem in
these examples is a mismatch between user's expectations and/or beliefs,
and what the software actually does.  The proposed solution, especially
the crypto-only one, is to partially change the software so that it
slightly more closely approximates user's mistaken beliefs.  However this
is only a partial fix and still leaves the fundamental problem in place.

Actually the problem has not been diagnosed correctly.  The issue is
not just that people will mistakenly believe that the software protects
the recipient identity.  The more important problem is that the software
fails to routinely protect the recipient identity (and other information).

Here is how the important problem manifests itself: Alice is a manager,
and before leaving on vacation she sends mail to Bob, her subordinate,
saying, "I got the go-ahead from the VP.  We are to put the plan we
discussed into action immediately.  I'll expect to see a full status
report when I return in a week."  She comes back a week later and Bob
didn't do anything!  "Didn't you get my email?"  "Sure, but I wasn't
sure it was legitimate."  "But didn't you see I signed it?"  "Yeah,
but I couldn't be sure you sent it to me.  It might have been meant for
someone else and redirected to me."

In the real problem, the failure is that the software did not routinely
protect the fact that Bob was the recipient.  Hence he could not go on the
assumption that he was the legitimate receiver, and Alice's intention was
not met.  The difference from the earlier examples is that in those cases,
someone mistakenly thought the recipient was protected.  In this example,
someone correctl

Re: crypto flaw in secure mail standards

[Peter Fairbrother]

A standard business letter has "From:" and "To:" addresses. It has a date.
It has a "Dear:", showing also (perhaps) who it is for. It has a "Yours:"
showing (perhaps) a relationship between the correspondents. It has a typed
name showing whose name it is sent in, and it has a signature which
authenticates _all_ of these.

It has these things because long experience shows that it needs them,
experience gained from disputes and court cases.

An electronic business letter should have the same things. "Dear:" has gone
by the boards in email, to my personal regret, but there is no excuse for
allowing e-mail without the "to" address being authenticated by the
signature. It is an elementary failure of protocol design.

-- Peter




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Enzo Michelangeli]

- Original Message -
From: "Greg Broiles" <[EMAIL PROTECTED]>
To: "Enzo Michelangeli" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 1:32 AM
Subject: Re: crypto flaw in secure mail standards

[...]
> The digital signature laws I've seen don't mention and don't support the
> notion of "non-repudiation", which seems to be an obsession among computer
> security people and a non-issue among legal people. The idea that
something
> is "non-repudiable" or unarguable or unavoidable is nonsense. I use it as
a
> clue detector - if someone talks about non-repudiation, they don't know
> much about US contract law.

I don't know about US contract law, but under Common Law repudiation _is_ an
issue, and that's why witnessing is required. Moreover, there are attempts
to change the legal implications of signing a document if this is done in an
electronic environment, shifting the onus of proof of the claim of forgery
to the (alleged) signatory. See e.g.
http://www.firstmonday.dk/issues/issue5_8/mccullagh/#m4 about the
controversial Article 13 of the UNCITRAL Model Law.

Enzo







-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ian BROWN]

Greg Broiles wrote:
>The digital signature laws I've seen don't mention and don't support the 
>notion of "non-repudiation", which seems to be an obsession among computer 
>security people and a non-issue among legal people.

Unfortunately, a lot of legal people have been convinced by the notion. 
The UK's law implementing the EU's digital signature directive allows
the burden of proof to be shifted so that the "signer" of a message has to 
prove they did NOT make it; the opposite to the physical signature situation. 
Many British banks' online terms and conditions say that customers are liable for any 
instructions authenticated by their password before it's revoked, never mind a digital 
signature.

Lots more info at:

Nicholas Bohm, Ian Brown and Brian Gladman. Electronic commerce: who carries the risk
of fraud? Journal of Information, Law and Technology, October 2000
http://elj.warwick.ac.uk/jilt/00-3/bohm.html

Jane K. Winn. The Emperor's new clothes: the shocking truth about digital
signatures and Internet commerce.
http://www.smu.edu/~jwinn/shocking-truth.htm
-- 
"Personal privacy was a transient state, starting when people no longer believed that 
God could see everything, and ending when governments decided they must fill the 
vacuum thus created." --Roger Needham





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ian BROWN]

>The right way to send encrypted mail is to
>create a mail message, encrypt it headers and all, and include that in a
>mail message of type multipart/alternative, with the alternative being a
>text message saying 'this mail is encrypted'.

Ned Freed suggested something along these lines on the OpenPGP working group 
list in 1998, but I don't know if anyone has implemented it :(

http://www.imc.org/ietf-openpgp/mail-archive/msg01941.html
-- 
"Spin doctors are the `rent boys' of politics." --Ken Follet





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ian BROWN]

Adam Back and I suggested a first pass of a way to do something like
this with PGP at a Usenix work-in-progress session, without having seen 
Radia's idea:

http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm
-- 
"Ken Clarke is a pudgy puffball." --Alan Clark MP





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ian BROWN]

>Forward secrecy is arguably a more important property of mail to have than
>authentication, and is much easier to build properly, since it doesn't get
>into the issues of identity. Unfortunately, none of the current mail
>standards support it at all.

A (very-slow-moving) Internet draft that I've been working on with Ben Laurie 
and Adam Back to do this for OpenPGP:

http://www.cs.ucl.ac.uk/staff/I.Brown/openpgp-pfs.txt
-- 
"We don't need to go through a debate about whether to try to censor the Internet: We 
cannot censor the Internet." --Ira Magaziner





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Ben Laurie]

Enzo Michelangeli wrote:
> 
> - Original Message -
> From: "Greg Broiles" <[EMAIL PROTECTED]>
> To: "Enzo Michelangeli" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Monday, June 25, 2001 1:32 AM
> Subject: Re: crypto flaw in secure mail standards
> 
> [...]
> > The digital signature laws I've seen don't mention and don't support the
> > notion of "non-repudiation", which seems to be an obsession among computer
> > security people and a non-issue among legal people. The idea that
> something
> > is "non-repudiable" or unarguable or unavoidable is nonsense. I use it as
> a
> > clue detector - if someone talks about non-repudiation, they don't know
> > much about US contract law.
> 
> I don't know about US contract law, but under Common Law repudiation _is_ an
> issue, and that's why witnessing is required. Moreover, there are attempts
> to change the legal implications of signing a document if this is done in an
> electronic environment, shifting the onus of proof of the claim of forgery
> to the (alleged) signatory. See e.g.
> http://www.firstmonday.dk/issues/issue5_8/mccullagh/#m4 about the
> controversial Article 13 of the UNCITRAL Model Law.

I think you are missing the point - repudiation is an issue, but nothing
is non-repudiable.

It seems pretty fundamental to me - I can deny anything. I might have a
hard time getting away with it, but at the very least you'll have to
demonstrate that my denial is implausible (which is why witnesses help).

It also seems to me that one of the problems with electronic signatures
is that witnessing is harder, at least if you want to be disconnected
from the witness. To make it stick as well as physical witnessing does
would require the witness to actually watch my screen and say "yes, he
definitely intended to sign that document I see on the screen" (note
that I say "intended" because witnesses could also be useful to protect
against fraudulent software). I'd guess that a phone call to discuss the
fingerprint of the document would have some value if presence cannot be
achieved, but it would be hard to deal with fraudulent software by that
mechanism. Reading the whole document over the phone is presumed to not
be an option :-)

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

In Boston 'til 1st July.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[James M Galvin]

The digital signature laws I've seen don't mention and don't support
the notion of "non-repudiation", which seems to be an obsession
among computer security people and a non-issue among legal
people. The idea that something is "non-repudiable" or unarguable or
unavoidable is nonsense. I use it as a clue detector - if someone
talks about non-repudiation, they don't know much about US contract
law.

My clue is just fine, but thanks for your concern.  Last time I checked
my favorite desktop dictionary to repudiate meant to reject as
unauthorized, you know, not a party to the contract.  Non-repudiation
would mean I can't reject it as unauthorized, you know, that I can not
say I am not party to the contract.  Would you please explain to me how
whether or not I am in fact an actual party to the contract has nothing
to do with US contract law?

Non-repudiation is not a legal concept in and of itself (and I never
said it was), but it is important to any lawyer who has to deal with any
dispute involving electronic information (which is what I meant although
perhaps not as well stated before).  It is a security service that is
important if not essential to electronic transactions that are
vulnerable to legal disputes (perhaps more so in the US than anywhere
else, but hey I'm not a lawyer so don't ask me).  It would also be fair
to say it is more important today than it was 12 years ago, when PEM was
first getting popular (for as popular as it got).  For that reason, Don
can call it a "flaw" if he wants to, but I prefer to think of it as the
"next bite" of the secure email problem which we could reasonably do
something about; it's certainly not a hard problem technically or a huge
oversight that got no attention at the time.

Jim



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Charlie_Kaufman]

>In fact, every secure e-mail
>protocol, old and new, has codified naïve Sign & Encrypt
>as acceptable security practice.  S/MIME, PKCS#7, PGP,
>OpenPGP, PEM, and MOSS all suffer from this flaw.

Actually, that's not true. The encrypted and signed email
functionality contained in Lotus Notes encrypts only body
fields and attachments, but signs the To:, From:, CC:,
Subject:, and TimeSent fields as well. And Lotus Notes predates
most if not all of the "standard" protocols.

I wouldn't call this a cryptographic flaw. I'd call it a flaw
in cryptographic engineering. And it's not a flaw borne out of
ignorance. The designers of the standard protocols knew about
the problem (I was there for some of them), but didn't think
their proposed standard would be acceptable if it "committed
layer violations" by extending signature coverage to data not
contained in their "layer". This is a classic example of
something a competent engineer can get right, but which a suite
of committees can't.

   --Charlie Kaufman
   ([EMAIL PROTECTED])

p.s. Ironically, Lotus Notes is transitioning from its
proprietary email format to S/MIME and trying to figure out how
to make it clear to customers that when they use the new
format, they don't get the protection they may have gotten used
to.






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Bill Frantz]

At 10:32 AM -0700 6/24/01, Greg Broiles wrote:
>The attack raised - at least as it's been summarized, I haven't gotten
>around to the paper yet - sounds like a good one to remember, but too
>contrived to be especially dangerous in the real world today. How often do
>you, or people you know, send short context-free messages to conclude
>important negotiations? ...

I think Greg is probably right when it comes to email messages.  The places
that attacks like this worry me the most are in program-to-program
messages.  The "Cross-Site Request Forgeries" confused deputy attack
(http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), described in
 and
, seem a
place where two-way SSL cryptographic authentication can make a bad
situation worse, because more value is likely to be entrusted to the
communication.

In this attack, a user's browser is tricked into sending certain URLs which
exercise authority without the user's permission.  The specific URLs can be
hidden behind redirect requests, making it difficult to recognize that the
attack is taking place.

Cheers - Bill


-
Bill Frantz   | The principle effect of| Periwinkle -- Consulting
(408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave.
[EMAIL PROTECTED] | fair use.  | Los Gatos, CA 95032, USA





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[Riad S. Wahby]

Derek Atkins <[EMAIL PROTECTED]> wrote:
> The problem is not at all with the crypto.  The problem is with the
> integration of the crypto with applications like e-mail.

In this spirit, I have produced a patch for Mutt that adds an option
to include the To:, From:, CC:, and Subject: headers at the end of PGP
signed messages.

This patch happens to interact somewhat with a previous patch I
produced that allows Mutt to optionally send PGP messages as
content-type text/plain for broken mail clients like nmh and Eudora,
so I have integrated both into a single patch.  

It applies against mutt-1.2.5i; I haven't tested it against others,
but I suspect it should work fine.

http://positron.mit.edu/pub/plaintextappend.patch
ftp://positron.mit.edu/pub/plaintextappend.patch

--
Riad Wahby
[EMAIL PROTECTED]
MIT VI-2/A 2002

5105



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[John Kelsey]

At 11:51 AM 6/23/01 -0400, Jeffrey I. Schiller wrote:
>On Fri, Jun 22, 2001 at 06:23:46PM -0400, Radia Perlman - Boston Center for 
>Networking wrote:
>> Actually I don't think Don was talking about that. Instead he was
>> talking about the danger of leaving things out of the
>> signature like the subject
>> line, the to field, the date, etc., that would allow someone to
>> take Alice's message out of context, and other people on the list
>> have explained that you need to have all stuff that matters be
>> covered by the signature, perhaps by having the user consciously
>> know what matters and include it in the body.
>
>Ah. This is why I always replicate the Subject field (and other important)
>fields in message that I sign for posterity (such as IESG action requests).

Basically, Don's attack amounts to showing that you can't safely use
PGP-signed or SMIME-signed messages by themselves to make a secure protocol
for contract signing.  It's a good thing to point out, but the basic
problem is hardly new--everyone knows that you can't, in general, make a
protocol between two machines secure when each signs their messages, but
neither includes anything to prevent cut-and-paste or replay attacks.  Now,
the specifics of how and whether the attack works depend on the details of
the messages--if each party quotes the whole of the previous message in
each new message, the attack will fail.  If each party sticks a timestamp
into the body of the message, some but not all attacks will fail.  (We
still fall prey to the interleaving attack, where Alice runs the
contract-signing by e-mail protocol with Bob and Charlie at the same time,
and Bob gets a signature on a statement "It's a deal!", and then gives that
to Charlie to claim that Alice said the same thing to him.

Also, note that anyone who understands what assurances the crypto can and
cannot provide here will not end up convinced that Alice intended to sign a
contract, they will end up convinced that they haven't enough evidence to
decide whether Alice intended to sign a contract.  (Unfortunately, there's
not much reason to expect a judge to know a lot about cryptography, so who
knows how this would really play out in court?)

It's easy enough to fix in various ways, by making the sequence of messages
between Alice and Bob part of a cryptographic protocol--make up a unique
session ID for this conversation, make sure Alice and Bob agree on it, and
then include that plus a message sequence number in each successive message
in the conversation.  Or whenever an e-mail is replying to an earlier
e-mail, include the SHA1 hash of the replied-to e-mail in this e-mail's
signature.  But none of that fixes the underlying problem, which is that
secure and signed e-mail is fundamentally a different thing that a
contract-signing protocol.

>   -Jeff
>
--John Kelsey, [EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: crypto flaw in secure mail standards

[dmolnar]

On 22 Jun 2001, Derek Atkins wrote:

> the set {Alice,Bob,Charlie,Daniel,Eve,Fred,Greg}, there is no way to
> know which of them sent it.  All members of the set must be mutually
> trusted, which means there is no way to sign a document that a set of
> people can verify comes EXACTLY from you.

Good point. There's always the approach of Alice sending each of
Bob,Charlie,Daniel,Eve,Fred,Greg a separate individual DVP, but this
incurs undesirable overhead. Plus Alice could send them all slightly
different messages and they'd be unable to prove to each other that she
was trying to trick them.

The original Impagliazzo, Jakobsson, Sako paper partially adresses this.
Their method of implementing designated verifier proofs is to perform
proofs of the form

"Either A is true OR I know secret key K."

In the peer-to-peer case, A is "document signed by Alice" and K is Bob's
private key. So Bob knows the document is real (assuming he hasn't lost
K), but no one else can be sure that he has not faked the proof/forged a
signature.

Their suggestion for multiple recipients is to have all the recipients
share a key K. Following your example, Bob,Charlie,Daniel,Eve,Fred, and
Greg generate a secret key using some distributed algorithm such that they
each have a share of the key and all shares are required to reconstruct.

Now when Alice sends the document to them, each one knows, given that
their share is safe, that the document really did come from Alice. An
outside observer, on the other hand, has to consider the possibility that
the group got together to forge a signature with their knowledge of K.
(This forgery can also be done in a distributed manner, so faking one
signature doesn't reveal the full key K to anyone).

There are at least two flaws with this approach. The first is that it
seems to require a new key K for each group of receipients. This may be
adressable through the use of group signatures. I haven't thought about it
much. I suspect this flaw is closest to the objection you raised.

The second flaw is tangential, but I think worth noting. The flaw is that
the members of the group must collaborate in order to forge a signature.
Whether or not the designation "works" depends on whether or not it is
plausible that the group members would collaborate.

For instance, suppose that a message is designated to Bob and Carol, who
are the heads of state of two warring countries? (The scene from "13 Days"
with its "these assurances can never be made public" comes to mind, but
isn't quite right).

It is not plausible that Bob and Carol would create a shared key K in the
first place, never mind collaborate to forge a signature. If the message
leaks and is published, Alice cannot convincingly argue that Bob and
Carol signed the message instead of her. This might be bad. So the issue
becomes not so much one of efficiency, but repudiation.

So how do you do designated verifier proofs with multiple
non-collaborating verifiers?

I think this may be partially adressed as follows:
Suppose Alice wants to designate a message to Bob and Carol. Alice sends
to Bob
M, X_B := E_C( DVS(M,Carol)) , DVS("X_B := E_C(DVS(M,Carol))", Bob)

and to Carol sends
M, X_C := E_B(DVS(M,Bob)), DVS( "X_C := E_B(DVS(M, Bob))", Carol)

Here M is the message, and by "X :=" I am giving a definition of X.
DVS(E,F) stands for "A non-interactive designated verifier proof of E
which is designated to F." E_B and E_C are public-key encryption using Bob
and Carol's public keys respectively. The notation is slightly
inconsistent as written, because by "DVS(M, Carol)" I really mean a
signature of M designated to Carol, while by "DVS( "X := E_C(DVS(M,
Carol))", Bob) I mean a proof that X is a valid encryption of a designated
verifier signature.

I claim that this gives us a signature in which

1) Carol can determine that M is signed by Alice
2) Carol can determine that M will be verified by Bob as
being signed by Alice if she presents X to Bob and he decrypts
it to find M
3) Carol cannot prove 1) or 2) to anyone else.

Proof:
1) The DVS("X_C := DVS(M,Bob)", Carol) proves that Alice
knows a signature from Alice designated to Bob on M. If Carol is
willing to assume Alice does not know Bob's private key,
this is enough. Otherwise she can require a separate
DVS(M, Carol).

2) The DVS(X_C := E_B(DVS(M,Bob)), Carol) convinces Carol that
Bob can decrypt X_C to obtain a valid designated verifier
signature of M. This is required to prevent Alice from sending
different messages to Bob and Carol; while it won't catch
Alice immediately, it will allow Bob and Carol to determine
that such cheating has occured (they exchange their X values and
find that they are different messages).

3) All these signatures are designated verifier for Carol.

and the above is similar for Bob.

For three designees, Bob, Carol,

non-repudiation, was Re: crypto flaw in secure mail standards

[Greg Broiles]

At 10:48 AM 6/25/2001 -0400, James M Galvin wrote:

>My clue is just fine, but thanks for your concern.  Last time I checked
>my favorite desktop dictionary to repudiate meant to reject as
>unauthorized, you know, not a party to the contract.  Non-repudiation
>would mean I can't reject it as unauthorized, you know, that I can not
>say I am not party to the contract.

"Unauthorized" does not mean "not a party to the contract".

Also, you seem to be confusing shifting evidentiary burdens with prevailing 
on an issue at trial. Or does "non-repudiation" now mean we won't bother 
with trials any more?

One of the basic problems with "non-repudiation" is that its proponents 
can't even which general body of law it exists within - e.g., is it an 
aspect of contract law? an evidentiary rule? a rule of civil or criminal 
procedure? Does it satisfy an existing burden of production, or persuasion 
.. or create a new one? Does it establish a rebuttable or a non-rebuttable 
presumption, or merely a permissible inference?

It's not at all clear to me that it's had the benefit of any real attention 
from anyone with a legal education, much less a careful explanation of how 
it'd fit into existing legal frameworks, and whether it rests upon existing 
statutes or caselaw or if it requires new legislation to take effect.

If you are aware of this scholarship, I would certainly appreciate a 
reference to it.

>   Would you please explain to me how
>whether or not I am in fact an actual party to the contract has nothing
>to do with US contract law?

Oh, that's a question that's very important to US contract law, which is 
why courts aren't about to abandon that question - or the admissibility or 
evaluation of evidence relevant to that question - to the result of some 
computations.

Even if it were to do so, how would the finder of fact learn of the result 
of the computations? By oral testimony? In court?

>Non-repudiation is not a legal concept in and of itself (and I never
>said it was), but it is important to any lawyer who has to deal with any
>dispute involving electronic information (which is what I meant although
>perhaps not as well stated before).

No, it's not. It's a silly distraction that raises at least as many 
questions as it purports to answer, and it doesn't even answer the hard 
questions about contract formation. As Jon Callas pointed out, the attack 
discussed here is really a semantic attack on the meaning of a message, not 
its construction or delivery. Disputes about contracts are not likely to be 
about which words are included in a contract (not if it's a fully 
integrated contract, anyway - and if it's not, non-repudiation and digital 
signatures are worse than worthless) - they're likely to be about what 
those words mean, and whether or not the parties' behavior was consistent 
with the meanings of the words . . . or what the appropriate relief is, if 
one or more parties breached.

Cryptography will never fix that problem. You will need humans to read the 
words and listen to arguments and arrive at a reasonable understanding of 
their meaning - and to hear testimony and look at evidence and decide who's 
right and who's wrong. There's no way to short-circuit all of that with a 
little extra math.

"Not a legal concept" is a critically important distinction - 
non-repudiation is a feature or service which has no corresponding demand 
or application in the real world. Yes, it is possible to imagine parallel 
universes where something like that would be neat. But this isn't one of them.

>   It is a security service that is
>important if not essential to electronic transactions that are
>vulnerable to legal disputes (perhaps more so in the US than anywhere
>else, but hey I'm not a lawyer so don't ask me).

I am a lawyer who's worked on a product for electronic transactions which 
used digital signatures - and I can tell you that there's very little 
customer interest and no real-world courtroom/litigator interest or relevance.

Non-repudiation might work in a lower-stakes or less-due-process 
environment like an in-house dispute resolution system, where there's no a 
priori expectation of fairness or reasonableness, and where one actor can 
mandate use of the system - e.g., if you have a signature from your manager 
on your vacation request, you get to take time off, even if it's later 
shown that the IT guy stole the keys off of a backup tape and signed a lot 
of vacation requests, because the finality of the decision/result is more 
important to the company than the expense of internal dispute resolution. 
On the other hand, I really can't identify a single application where I 
think that'd make sense - implementing a PKI system robust enough to 
support non-ludicrous non-repudiation is very expensive, and I don't think 
there'd be a lot of institutional resolve behind the "non-repudiation" rule 
of law if in fact the PKI system were misused - e.g., the IT guy gives 
everyone 3 months of vacati

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Rodney Thayer]

At 02:07 PM 7/5/01 -0700, Greg Broiles wrote:
 >... using a PKI non-repudiation scheme in this instance might be helpful, 
though it's worth keeping in >mind that it rests on the assumption that 
end-users can and will preserve the security of a couple of >big numbers 
(their private keypair) when currently they're frequently able to escape 
liability by >claiming to have experienced a security breach related to 
their preservation and use of a single, much >shorter pair of numbers - 
their credit card number and expiration date.

people frequently are asked to sign usage agreements that explicitly state they
are responsible for protecting their password/key material.  This is 
DIFFERENT from
credit card numbers -- nobody asks you to sign something that says
you'll keep your credit card number private.

Now, the validity of those agreements may or may not be untested, but they 
exist, so the
path to establishing case law probably exists.

...rodney


"the two most dangerous things on the internet are: geeks pretending to be 
lawyers,
and, lawyers pretending to be geeks"




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

one of the biggest problems that has led to most of the regulations is the
ease that account-number harvesting can occur and then the account number
used in fraudulent, non-authenticated transactions. The SET-like protocols
didn't address this issue. However, there is a huge amount of stuff going
on about the need for implementing absolute perfect security at the
millions of merchant sites scattered all over the world ... where there is
an absolute guarentee that at each and every site, harvesting by either
external agents and/or internal agents would absolutely never occur.

by contrast the X9.59 standard (US ANSI financial standards bodies and
pushing forward to international ISO) does address this issue ... where it
allows that the probability of absolte security and each and every web-site
implemented in the world never fails and that there still won't be
fraudulent transactions in association with any kind of (internal or
external) account number havesting (aka charter given the X9A10 working
group in the definition of X9.59 was to preserve the integrity of the
financial infrastructure for all retail, account-based, electronic
transactions. The claim also is that X9.59 definition is also identity
agnostic and can suppurt EU regulations/guidelines that retail transactions
need to not have identity information (i.e. name information embossed on
the plastic and recorded on the magstripe).

misc. ref:

http://www.garlic.com/~lynn/

The X9.59 standard can be obtained from the ANSI publication web site.

http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000


[EMAIL PROTECTED] on 7/5/2001 wrote:




Implementing non-repudiation as a countermeasure versus spurious "do not
recognize" chargebacks seems to depend on all of the following:

(a) development and widespread adoption of a secure platform for key
storage and Internet use, like the system "whose user interface and
underlying technology is such that the signature is unlikely to be forged .
." described by James Donald above

(b) merchants forcing customers to adopt that platform and SET-like
procedures in order to carry out transactions

(c) changing the Fair Credit Billing Act to make it more difficult or
impossible for consumers to dispute items on their bills.







-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

true ... but it wasn't standard business practice ... there were all sorts
of options ... the issue was what were the standard business practices
actually followed.

I believe that there is a thread from two years ago on this specific
subject ... where somebody associated with SET explicitly stated that the
standard business practices were not designed to preclude the merchant from
having the PAN.

I can look up the discussion if you are interested.





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

... and the x9.59 solution was designed to be applicable to "all"
account-based, electronic payments  not just credit ... but "all".

much of the regs. are specific to credit (because of the ease that
account-number harvesting can lead to fraudulent, non-authenticated
transactions)  ... while the x9.59 approach can not only be used to address
credit but debit as well (one of the other account-based, electronic
payments).

an example is the completed nacha pilot

again refs at

http://www.garlic.com/~lynn/






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Eric Rescorla]

[EMAIL PROTECTED] writes:
> one of the biggest problems that has led to most of the regulations is the
> ease that account-number harvesting can occur and then the account number
> used in fraudulent, non-authenticated transactions. The SET-like protocols
> didn't address this issue.
How so? In at least one mode, SET denied the merchant the PAN.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

specific ref.
http://www.garlic.com/~lynn/aepay3.htm#sslset1

in a thread with one of the SET people from visa ... they stated that it
was not designed to prevent a valid merchant from getting the PAN  . in
fact, that there are standard credit card businness process that require
the merchant to have the PAN and that the PAN was alwas returned to a valid
merchant from the payment gateway. I had made the assertion that possibly
the SET option could have been overriden ... which would have inhibited the
ability of the merchant to perform normal credit card business processing
... and was corrected that it was always designed that the PAN be returned
to a valid merchant (and not to inhibit the merchant from being able to
execute standard business processes).


misc. set references from past discussions
http://www.garlic.com/~lynn/aadsm3.htm#kiss6  KISS for PKIX. (Was: RE: ASN.1 vs XML 
(used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr  Comments from 2nd LB on DSTU X9.59
http://www.garlic.com/~lynn/ansiepay.htm#theory  Security breach raises questions 
about Internet shopping
http://www.garlic.com/~lynn/aepay3.htm#disputes  Half of Visa's disputes, fraud result 
from I-commerce (more)
http://www.garlic.com/~lynn/aepay3.htm#votec  (my) long winded observations regarding 
X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#sslset1  "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay3.htm#sslset2  "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay4.htm#visaset  Visa Delicately Gives Hook to SET 
Standard
http://www.garlic.com/~lynn/aepay4.htm#visaset2  Visa Delicately Gives Hook to SET 
Standard
http://www.garlic.com/~lynn/aepay4.htm#3dssl  VISA 3D-SSL
http://www.garlic.com/~lynn/aepay6.htm#gaopki4  GAO: Government faces obstacles in PKI 
security adoption
http://www.garlic.com/~lynn/aepay6.htm#ecomich  call for new measures: ICH would be 
glad to help
http://www.garlic.com/~lynn/aadsmore.htm#setjava  javasoft SET - NO!

misc. electronic commerce discusions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3






Eric Rescorla <[EMAIL PROTECTED]>@rtfm.com on 07/07/2001 11:54:44 AM

Please respond to EKR <[EMAIL PROTECTED]>

Sent by:  [EMAIL PROTECTED]


To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Greg Broiles <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James M Galvin
  <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
  [EMAIL PROTECTED]
Subject:  Re: non-repudiation, was Re: crypto flaw in secure mail standards


[EMAIL PROTECTED] writes:
> one of the biggest problems that has led to most of the regulations is
the
> ease that account-number harvesting can occur and then the account number
> used in fraudulent, non-authenticated transactions. The SET-like
protocols
> didn't address this issue.
How so? In at least one mode, SET denied the merchant the PAN.

-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

for a fuller discussion of SSL & SET discussion ... set x9a10 mailing list
archives

http://lists.commerce.net/archives/ansi-epay/199905/maillist.html

the above has the postings in reverse cronological order.

but, basically the bottom line is that there are a number of merchant
credit card business process that require the merchant to have the PAN (or
merchant credit card stuff doesn't work).

specific posting (from somebody at visa):

http://lists.commerce.net/archives/ansi-epay/199905/msg9.html







Eric Rescorla <[EMAIL PROTECTED]>@rtfm.com on 07/07/2001 11:54:44 AM

Please respond to EKR <[EMAIL PROTECTED]>

Sent by:  [EMAIL PROTECTED]


To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Greg Broiles <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James M Galvin
  <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
  [EMAIL PROTECTED]
Subject:  Re: non-repudiation, was Re: crypto flaw in secure mail standards


[EMAIL PROTECTED] writes:
> one of the biggest problems that has led to most of the regulations is
the
> ease that account-number harvesting can occur and then the account number
> used in fraudulent, non-authenticated transactions. The SET-like
protocols
> didn't address this issue.
How so? In at least one mode, SET denied the merchant the PAN.

-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]