Re: non-repudiation, was Re: crypto flaw in secure mail standards
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
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]
Re: non-repudiation, was Re: crypto flaw in secure mail standards
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
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
... 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
[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: crypto flaw in secure mail standards
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
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
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
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
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
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
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 http://archives.neohapsis.com/archives/bugtraq/2001-06/0170.html and http://archives.neohapsis.com/archives/bugtraq/2001-06/0196.html, 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
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
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
- 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
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]
crypto flaw in secure mail standards
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
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
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
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 that it's true. Alice didn't. Bob
Re: crypto flaw in secure mail standards
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]
crypto flaw in secure mail standards
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]
Re: crypto flaw in secure mail standards
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
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]
