Re: DOJ proposes US data-rentention law.
Under this proposed law, will ISPs have to scan *all* SMTP traffic and record the envelope, or only the traffic for which they actually do SMTP forwarding? If the latter is the case, we can simply go back to the original end-to-end SMTP delivery model; no POP/IMAP or any of that stuff. If the former is the case, well, so long as they don't outlaw crypto, ISPs can't sniff SMTP going over IPsec, now, can they? Of course, outlawing crypto or declaring that anyone who terminates an SMTP connection, including end-users, is considered an ISP for the purposes of the law solves their problem. /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RSA getting rid of trusted third parties?
I came across this interesting announcement by RSA: http://www.rsasecurity.com/news/pr/2002/020619.html Particularly from the above announcement: By using this solution, customers' Web server certificates generated and issued by their RSA Keon Certificate Authority (CA) software are designed to be automatically validated - and therefore trusted - by popular Web browsers, e-mail packages and other applications that leverage the recognized issuer lists of these Web browsers. This announcement appears to completely break down the trust model assuming anybody can host a Keon CA that will issue trusted certificates. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
Doesn't a standard digital signature plus hashcash / client puzzles achieve this effect? The hashcash could be used to make the client to consume more cpu than the server. The hashcash collision wouldn't particularly have to be related to the signature, as the collision would just act as a proof-of-work entitling the client to have the server verify the accompanying signature. Adam On Thu, Jun 20, 2002 at 11:08:37PM -0700, Bill Frantz wrote: I have been thinking about how to limit denial of service attacks on a server which will have to verify signatures on certain transactions. It seems that an attacker can just send random (or even not so random) data for the signature and force the server to perform extensive processing just to reject the transaction. If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. This might result in a better balance between the resources needed by the attacker and those needed by the server. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Followup: [RE: DOJ proposes US data-rentention law.]
Two points: 1. According to Poulson, the DOJ proposal never discussed just what would be logged. Poulson compared it to the European Big Brother legislation, which required storage to Web browsing histories and email header data. 2. After I posted the same info to /. http://slashdot.org/articles/02/06/19/1724216.shtml?tid=103 (I'm the 'Anonymous Coward' in this case), Kevin updated his article. The new version may be found at: http://online.securityfocus.com/news/489 The relevant portions read: - start quote - U.S. Denies Data Retention Plans The Justice Department disputes claims that Internet service providers could be forced to spy on their customers as part of the U.S. strategy for securing cyberspace. By Kevin Poulsen, Jun 19 2002 12:24PM [...] But a Justice Department source said Wednesday that data retention is mentioned in the strategy only as an industry concern -- ISPs and telecom companies oppose the costly idea -- and does not reflect any plan by the department or the White House to push for a U.S. law. [...] - end quote - Peter Trei -- From: David G. Koontz[SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 20, 2002 10:57 AM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: DOJ proposes US data-rentention law. Trei, Peter wrote: - start quote - Cyber Security Plan Contemplates U.S. Data Retention Law http://online.securityfocus.com/news/486 Internet service providers may be forced into wholesale spying on their customers as part of the White House's strategy for securing cyberspace. By Kevin Poulsen, Jun 18 2002 3:46PM An early draft of the White House's National Strategy to Secure Cyberspace envisions the same kind of mandatory customer data collection and retention by U.S. Internet service providers as was recently enacted in Europe, according to sources who have reviewed portions of the plan. In recent weeks, the administration has begun doling out bits and pieces of a draft of the strategy to technology industry members and advocacy groups. A federal data retention law is suggested briefly in a section drafted in part by the U.S. Justice Department. If the U.S. wasn't in an undeclared 'war', this would be considered an unfunded mandate. Does anyone realize the cost involved? Think of all the spam that needs to be recorded for posterity. ISPs don't currently record the type of information that this is talking about. What customer data backup is being performed by ISPs is by and large done by disk mirroring and is not kept permanently. I did a bit of back of the envelope calculation and the cost in the U.S. approaches half a billion dollars a year in additional backup costs a year without any CALEA type impact to make it easy for law enforcment to do data mining. The estimate could easily be low by a factor of 5-10. AOL of course would be hit by 40 percent of this though, not to mention a nice tax on MSN. Call it ten cents a day per customer in fee increases to record all that spam for review by big brother. I feel safer already. Whats next, censorship? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
It's already been thunk of. check the literature on hash cash. Basically, the idea is that the server presents a little puzzle that requires linear computation on the client's side. (same algorithm as minsky used for his time-lock). The client has to present the solution of the puzzle with a valid request. To extend the idea to signatures, all you really have to do is program the server to create puzzles that will take at least as much computation to solve as it requires to check the signature. And of course it checks the solution to the puzzle (using a single modular-power operation, which is relatively cheap) before it checks the signature itself. Bear On Thu, 20 Jun 2002, Bill Frantz wrote: I have been thinking about how to limit denial of service attacks on a server which will have to verify signatures on certain transactions. It seems that an attacker can just send random (or even not so random) data for the signature and force the server to perform extensive processing just to reject the transaction. If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. This might result in a better balance between the resources needed by the attacker and those needed by the server. Cheers - Bill - Bill Frantz | The principal 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
A DoS would not pitch one client against one server. A distributed attack using several clients could overcome any single server advantage. A scalable strategy would be a queue system for distributing load to a pool of servers and a rating system for early rejection of repeated bad queries from a source. The rating system would reset the source rating after a pre-defined time, much like anti-congestion mechanisms on the Net. Fast rejection of bogus signatures would help, but not alone. Cheers, Ed Gerck Bill Frantz wrote: I have been thinking about how to limit denial of service attacks on a server which will have to verify signatures on certain transactions. It seems that an attacker can just send random (or even not so random) data for the signature and force the server to perform extensive processing just to reject the transaction. If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. This might result in a better balance between the resources needed by the attacker and those needed by the server. Cheers - Bill - Bill Frantz | The principal 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA getting rid of trusted third parties?
On Fri, Jun 21, 2002 at 08:28:40AM -0500, [EMAIL PROTECTED] wrote: I came across this interesting announcement by RSA: http://www.rsasecurity.com/news/pr/2002/020619.html Particularly from the above announcement: By using this solution, customers' Web server certificates generated and issued by their RSA Keon Certificate Authority (CA) software are designed to be automatically validated - and therefore trusted - by popular Web browsers, e-mail packages and other applications that leverage the recognized issuer lists of these Web browsers. This announcement appears to completely break down the trust model assuming anybody can host a Keon CA that will issue trusted certificates. But haven't browsers supported ceritificate chaining for years? As far as I can tell, that's all this is - RSA issues you a cert which says that you are trusted to create additional certificates (presumably just for entities within your organisation). The trust model doesn't break down just because anyone can create a valid X.509 certificate. There still has to be a valid chain of trust leading back to a trusted party (RSA, in this case). If that trust is abused, then RSA can revoke your cert and break the chain. Ian Clelland [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RSA getting rid of trusted third parties?
From: Ian Clelland [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 2:48 PM On Fri, Jun 21, 2002 at 08:28:40AM -0500, [EMAIL PROTECTED] wrote: I came across this interesting announcement by RSA: http://www.rsasecurity.com/news/pr/2002/020619.html Particularly from the above announcement: By using this solution, customers' Web server certificates generated and issued by their RSA Keon Certificate Authority (CA) software are designed to be automatically validated - and therefore trusted - by popular Web browsers, e-mail packages and other applications that leverage the recognized issuer lists of these Web browsers. This announcement appears to completely break down the trust model assuming anybody can host a Keon CA that will issue trusted certificates. But haven't browsers supported ceritificate chaining for years? As far as I can tell, that's all this is - RSA issues you a cert which says that you are trusted to create additional certificates (presumably just for entities within your organisation). The trust model doesn't break down just because anyone can create a valid X.509 certificate. There still has to be a valid chain of trust leading back to a trusted party (RSA, in this case). If that trust is abused, then RSA can revoke your cert and break the chain. Maybe I am reading more into it then exists but the bullet in the document says it will: Reduce help desk calls from end-users related to untrusted certificates That and the other language lead me to believe they have a trusted root already loaded in my browser that they let anybody authenticate to that is willing to buy their certificate authority software and that my browser will think those certificates are fine. I just hope that none of the private keys of all these (many probably unsecured) CAs leak. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA getting rid of trusted third parties?
At 11:48 AM 6/21/2002 -0700, Ian Clelland wrote: The trust model doesn't break down just because anyone can create a valid X.509 certificate. There still has to be a valid chain of trust leading back to a trusted party (RSA, in this case). If that trust is abused, then RSA can revoke your cert and break the chain. a) it isn't clear to me that RSA would have the right to revoke the organisations certificate; maybe they build it into their license agreement. b) browsers *don't check* the revocation status on certificates, and the field that points to the server for the revocation list is almost never filled in anyway. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
Ed Gerck wrote: A scalable strategy would be a queue system for distributing load to a pool of servers and a rating system for early rejection of repeated bad queries from a source. You could also vary the amount of hashcash required depending on the number of bad signatures you are receiving. So normally you would require no hashcash, so the clients don't have to expend CPU cycles. Then as the number of bad signatures increases, you step up the amount of hashcash so that you can continue coping. Interestingly you ought to be able to calculate the amount of hashcash required to keep the flow of bad signatures manageable. Suppose your current hashcash requirement is x, and bad signatures are arriving at twice the speed your crypto accelerator can cope with. Then, assuming that the hashcash calculation is the dominant cost for the attackers, you need to double your requirement to 2x. -- Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: DOJ proposes US data-rentention law.
ji wrote: Under this proposed law, will ISPs have to scan *all* SMTP traffic and record the envelope, or only the traffic for which they actually do SMTP forwarding? If the latter is the case, we can simply go back to the original end-to-end SMTP delivery model; no POP/IMAP or any of that stuff. If the former is the case, well, so long as they don't outlaw crypto, ISPs can't sniff SMTP going over IPsec, now, can they? IPSec is one solution, though I believe an easier way to deal with the recent email data retention proposals in the US (and already existing legislation in the EU) is the following: Locate the button in your MUA that's labeled Use secure connection or something to that effect, search the docs for your MTA for the words STARTTLS, relaying, and potentially SASL, don't use your ISP's smtp server, encourage those that you are communicating with to do the same, and the email data retention laws will be of no bother to you. Anybody that's using postfix as their MTA is welcome to contact me for more detailed instructions, though the above general instructions will work for any decent modern MUA/MTA. Check my mail headers for an example of what I mean. --Lucky tap as much of my 3DES encrypted traffic as you desire Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA getting rid of trusted third parties?
On Fri, Jun 21, 2002 at 02:54:25PM -0500, [EMAIL PROTECTED] wrote: Maybe I am reading more into it then exists but the bullet in the document says it will: Reduce help desk calls from end-users related to untrusted certificates It makes sense, though, that a company should be able to issue certificates for servers belonging to various departments within the company. The organisation knows its own internals far better than RSA does. Why should RSA/Verisign/whoever be responsible for signing such certificates? I see no benefit to having such a wide, flat web of trust. What root CAs are good at, and what they should be doing, is authenticating the organisation itself. They can verify that the organisation exists as described, and that the private key really is controlled by someone authorised within that organisation. This makes them fairly well suited to handing out certificates for the public face of the organisation. The high cost of this process, though, means that organisations tend to have very few secure servers, and if they need to secure any machines for internal use, they're not going to ask a root CA to do it; they'll just make one and sign it themselves, and probably put a note on the page which says, We know that your browser will claim this cert is invalid; just accept it anyway. This sort of practice is what leads to all of the help-desk calls, and is probably more damaging to PKI, ultimately, than letting RSA issue a certificate which says, The owner of this certificate is trusted to sign certificates within the organisation XYZ. If the alternative is to have people conditioned to simply click Proceed whenever they see an unrecognised signer, I'd much rather have this system. That and the other language lead me to believe they have a trusted root already loaded in my browser that they let anybody authenticate to that is willing to buy their certificate authority software and that my browser will think those certificates are fine. They already have such a root certificate in your browser. Nowhere in the press release do they say that they will let anyone and everyone get the CA software and start signing certificates for every site and its dog. I just hope that none of the private keys of all these (many probably unsecured) CAs leak. This shouldn't be a problem, as long as the signing certificate can only be used to sign certificates within that organisation. In that case, if one does get compromised, then that company has a major PR problem, but it's not the end of the world for everyone else. They should have taken better care of the keys. My whole argument, of course, rests on the assumption that these certificates can be restricted in this way. I don't know enough about the format of X.509 certs to say for sure that this is true. Someone on this list must, though. Ian Clelland [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Shortcut digital signature verification failure
Bill wrote: I have been thinking about how to limit denial of service attacks on a server which will have to verify signatures on certain transactions. It seems that an attacker can just send random (or even not so random) data for the signature and force the server to perform extensive processing just to reject the transaction. If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. This might result in a better balance between the resources needed by the attacker and those needed by the server. Neat idea. So neat in fact that RSA Security has a patent on it. :-) Sorry, I don't have the patent number handy. --Lucky - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
