Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Since DNS is a online positive list you change the database ... and voila it is updated. This is the scenario for credit cards going from pre-70s technology with plastic cards and the monthly revokation booklet mailed out to all merchants. The credit card industry transitioned to online infrastructure where it transactions are denied by updating the online database. It eliminates the revokation process, since there aren't an unknown number of copies of static, stale credentials/certificates floating around the world potentially being presented to an unknown variety of relying parties. DNS caching is the closest equivalent of the certificate paradigm of static, stale copies floating around the world. The two slight differences are that cached stale, static entries tend to have very short lifetimes ... they come into creation by activities by the relying-party (not the entity being authenticated) and tend to have very short lifetimes of a few hours to at most a day. However, relying-parties have the choice of going directly to the root and obtaining the current copy a function somewhat filled in the PKI world by OCSP although OCSP is just a check about whether the current, static, stale copy in a relying-party's possession is current ... not what the current entry is.. From information theory standpoint, stale, static certificates are logically a form of long-lived, distributed, replicated, r/o, cache entries. Cache entry semantics have been studied in some detail in areas like distributed file systems and multiprocessor consistent shared memory caches, etc. With short-lived r/o, distributed cache entires (like DNS) ... there is a trade-off involving 1) entry life-time, 2) frequency of change, 3) impact of dealing with stale entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as item potent, most client implementations have this 8k cache that can be stale. Given high value /or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). random, unrelated refs to past life working on processor cache design, distributed filesystems, and distributed databases http://www.garlic.com/~lynn/subtopic.html#smp http://www.garlic.com/~lynn/subtopic.html#hacmp -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Given high value /or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). ok... does anyone else want to touch a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing. www.rs.net has some information. - 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: Is cryptography where security took the wrong branch?
. slightly related discussion of the security proportional to risk and the vulnerability represented by the merchant transaction file http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe??? misc. recent SET refs: http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch? http://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch? -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:19 PM 9/7/2003 -0600, Anne Lynn Wheeler wrote: Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request eliminating all the identification gorp (and also done w/o the use of certificates). misc. additional recent musings: http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new) The Database gaps make ID fraud easier, GAO says http://www.gcn.com/vol1_no1/daily-updates/23446-1.html is somewhat analogous to the SSL domain name certificate problem ... a primary purpose for existing is to authenticate that the website you think you are talking to is the website you are talking to. The problem is that the domain name infrastructure has a database of domain name owners but no real good infrastructure ... and the CA/PKI operations doing SSL domain name certifications are disjoint from the domain name infrastructure operations. As a result effectively the CA/PKI industry has to treat requests for SSL domain name certificates effectively as if it was a random person walking in from the street ... and then they have to try and match up such seemingly random requests ... with what little bit of information that they can extract from the domain name infrastructure (seeing if they can establish an identity in the real world based on the DNS database information ... and see if that identity then can be matched against the identity of the entity requesting the certificate). Adding a public key to the domain name infrastructure database as part of the domain name registration process then eliminates the requirement of trying to establishing corresponding identities in the real world ... and it just reduces to a question of authentication. Of course, the bottom line is if the domain name infrastructure has a real-time database of public keys for authentication purposes in part for use by the CA/PKI industry for authenticating SSL domain name certificate requests for use in authentication operations the use of the domain name infrastructure's authentication public keys don't have to just be restricted to authentication use by the CA/PKI industry. In fact, domain name infrastructure authentication public keys could be used to effectively for authentication operations that actually subsume the SSL domain name certificates authentication operations. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote: Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from ... while SET, 3d-secure, etc may have been designed for all sorts of reasons I guess my point was that w/o a adequately specified threat model for the primary vulnerabilities ... there turned out to be little effective difference between the use of SET and the use of SSL (regardless of what the designers may have original thot). Also technology adoption/uptake typically requires the transition to be less painful than the problem it is fixing. SSL was already in the market space ... so SET had to demonstrate that it was incrementally better (not effectively the same as for the major vulnerabilities) in order to justify its significantly more difficult and costly deployment. The other issue that has been the bane of major PKI/certificate deployments (and I've repeatedly raised the issue) ... is that certificate-based operations typically have the key owner paying for the certificate while the major benefit accrues to the relying-party ... the the key/certificate owner. In the case of SET ... there was the consumer payng for their certificate and the merchant not only receiving a better than MOTO-discount (making interchange transactions with the SET flag turned on ... somewhat suspecious) ... but also the possibility that the transaction would be treated as authenticated and potentially shifting the burden of proof in a dispute from the merchant to the consumer. There was the possibility that not only would the consumer be footing the bill (buying their own certificate) for the sole benefit of reducing what the merchant paid on the transaction but there was also speculation that it might also be used to make it more difficult for the consumer (there was sporadic mention of shifting the burden of proof from the merchant to the consumer in a dispute). At least in the SSL domain name certificate, the merchant pays because of some belief that it will help attracted (internet) consumers/business. In the SET/PKI scenario ... it was nearly impossible to figure out a value proposition for the consumer where the consumer is footing the (certificate) bill ... that turns out to be totally for the benefit of the merchant. It wasn't so much that cryptography took a wrong branch ... but many of the PKI business models don't conform to any sane business operation with the entity (key-owner) footing the bill not getting any benefit ... and all the benefit going to the relying-party. The other generalized PKI issue (again not just SET) ... is any contract tends to be between the CA?PKI and the consumer aka the entity in a contract that purchases something. Frequently is no contractual relationship between the relying-parties who effectively the sole reason that the certificates exist ... and the CA/PKI. As mentioned elsewhere, the GSA PKI has attempted to somewhat address this by having all relying-parties sign contracts with the GSA and all the CA/PKI certificate issuing entities have a contract with the GSA where they are effectively issuing certificates on behalf of the GSA. Those set of contracts then preovide the legal foundation for some generic reason for relying-parties to do anything with certificates (since the relying-parties and the CA/PKI agency, aka GSA ... have contractual relationship and therefor a legal reason to deal with certificates). The slightly different SET scenario ... the associations just told the merchants that they would be charged less per transaction ... aka instead of MOTO (mail order, telephone order) discount, they could get something closer to card present discount. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
- Original Message - From: Ian Grigg [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 12:01 AM Subject: Re: Is cryptography where security took the wrong branch? That's easy to see, in that if SSL was oriented to credit cards, why did they do SET? (And, SHTTP seems much closer to that mission, on a quick reading, at least.) Actually they do target very different aspects. SET, 3D-Secure, and any other similar have a different target then SSL. To understand this it is important to realize that instead of the usual view of two-party transactions, credit card transactions actually take 3 parties; Issuer, Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also be applied to the Seller-Issuer communication, but on a transaction basis it offers nothing for the Issuer-Buyer (the important one for minimizing costs for the Issuer). SET/3D-Secure/etc address this through various means but the end target is to create a pseudo-Buyer-Issuer link, through the Seller. This allows the Issuer to minimize costs (less chance of having to make a call) and because it is behind the scenes technology has no reason to be accompanied by a reduction in fees (and actually because of the reduced likelihood of buyer fraud, it may be possible to charge the seller _more_). In the end SSL and SET/3D-Secure/etc target entirely different portions of the problem (the former targets seller fraud against the buyer, latter seller against issuer). Both of these are important portions, of course the real upside of SET/3D-Secure/etc is that the seller doesn't have a choice, and the fees in accordance with the fraud-reduction may very well increase the costs to the seller, the buyer costs of course stay the same. End result: lower fraud, increased fees-higher profit margins. However, if it meets expectations, it is entirely possible that all legitimate parties (non-fraud entities) will see improved profits (seller has reduced fraud and charge-backs, buyer less likelihood of the $50 penalty, issuer higher fees). Will it meet those expectations? I have no idea. Joe Trust Laboratories Changing Software Development http://www.trustlaboratories.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:01 AM 9/7/2003 -0400, Ian Grigg wrote: Reputedly, chargeback rates and fees in the fringe industries - adult for example - can reach 50%. But, instead of denying those uses of the card - hygiene - issuers have encouraged it (...until recently. There is now a movement, over the last year, to withdraw service from the fringe industries, but, it is because of additional risks being added, not the risks of fraud or user loss. Visa is doing it, Mastercard is waiting and seeing.) a webhosting company presented some numbers at some standards meeting that they handled ten websites (all with monthly hits higher than the number one in the published monthly hit rankings) ... five were adult-type downloads and five were various kinds of (non-adult) software downloads. The adult-type charge backs were comparable to mainstream brickmortar upscale retail outlets while the mainstream software downloads was on the order of fifty percent. It seemed that the people that download software are much more fringe than the types that download adult material (i believe they threw in some snide comments about the character f people that download software). as I've mentioned before ipsec had been progressing very slowly in ietf for some time. in '94 ... you saw VPN being introduced at router working group (fall san jose meeting?) and introduction of SSL. both could be considered the domain of ipsec. Several of the router vendors didn't have processors capable of doing the crypto for VPN ... so you somewhat saw vaporware product announcements following the san jose meeting and VPN didn't make much progress until more router vendors had processors capable of handling the crypto load. the ipsec people seemed to evnetually come to terms with vpn by referring to it as lightweight ipsec (so the vpn people got to refer to ipsec as heavyweight ipsec). also in 94 you started to see SSL deployment basically a transport level ipsec feature implemented by applications (could be considered because ipsec was having such a hard time progressing). minor past refs: http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec what i remember from the time was that SSL was thought as handling all of the shopping experience not just the credit card part but the feedback was that doing everything thru SSL cut the thruput capacity by about a factor of five (or you could handle five times as much traffic on the same hardware not using SSL).. The result was rather than using SSL for all commercial activity ... it was cut back to just handling the credit card part. Basically, SSL was being used for hiding the credit card number while in transit (over the internet). However, almost all the exploits have been from harvesting credit card files even when it would be possible to sniff non-encrypted credit card transmission. That issue is somewhat that you can be very targeted and quickly get possibly hundred thousand credit card numbers or you could put up a listening post and hope that you run across several a day (or maybe even an hour). SET came out after SSL ... and made extensive use of public key operations. I reported a public key operation performance profile for SET within a couple weeks after the original specification ... which several people working on SET claimed to be one hundred times too slow. It was probably just wishful thinking on their part since when they had some running prototype ... the profile was within a couple percent of measured. An issue was that SET was at least an order of magnitude more resource intensive than SSL ... and the only thing it did was protect credit card information in transit; basically it was only addressing the same (credit card) threat model as SSL but with significantly more overhead (having possibly hundred times more PKI didn't actually make things more secure). lots of past comments about what SSL does for credit card transactions: http://www.garlic.com/~lynn/subpubkey.html#sslcerts lots of recent comments in sci.crypt about eliminating certificates from SSL by collapsing the public key stuff into DNS: http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough. I don't think so. One of the things I'm running into increasingly with HTTPS is that you can't do an end-to-end check on a cert. That is, if I have some guy logging into some site using a client cert, and that site then makes a back-end connection to another site, there's no way it can prove to the back-end site that it has the real guy online (without playing nasty tricks with the guts of SSL, anyway), and there's certainly no way to prove that some particular response came from him. Signing stuff would deal with this trivially. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: Eric Rescorla wrote: ... The other thing to be aware of is that ecommerce itself is being stinted badly by the server and browser limits. There's little doubt that because servers and browsers made poorly contrived decisions on certificates, they increased the overall risks to the net by reducing the deployment, and probably reduced the revenue flow for certificate providers by a factor of 2-5. I doubt that. Do you have any data to support this claim? Sure. SSH. That's not data, it's an anecdote--and not a very supportive one at that. As far as I know, there isn't actually more total SSH deployment than SSL, so you've got to do some kind of adjustment for the total potential size of the market, which is a notoriously tricky calculation. It's more than an anecdote. If I quote from your slides, SSH has achieved an almost total domination of where it can be deployed. Wherever there are Unix servers, we suspect the domination of SSH. (I haven't got a good figure on that. Some stats have been done Neils Provos and Peter Honeyman in a paper, but I can't interpret the results sufficiently to show SSH server distribution, nor penetration [1]. It's now a hot topic, so I believe the figures will become available in time.) Do you have any actual data or did you just pull 2-5 out of the air? There is a middle ground between data and the air, which is analysis. I've been meaning to write it up, but I'm working on the SSL threat model right now. It's about take up models. HTTPS' model of take-up is almost deliberately designed to reduce take-up. It uses a double interlocking enforcement on purchase of a certificate. Because both the browser and server insist on the cert being correct and CA-signed and present, it places a barrier of size X in front of users. I don't know where you got the idea that the server insists on cert correctness. Neither ApacheSSL nor mod_SSL does. I take the following approach here. I think that for Apache to promote the interests of the users, it should configure automatically to run SSL, and automatically generate a self-signed cert on install (unless there is one there already). I admit I haven't looked to see whether that is reasonable or possible, but I gather it does neither of those things, and it certainly doesn't make doing self- signed certs so easy. Oh, and Apache does lead one astray by calling the self-signed cert a snake-oil cert. This misleads the users into thinking there is something wrong with a self-signed cert. I'm not sure how easy that is to correct. Instead, if there were two barriers, each of half-X, being the setup of the SSL server (a properly set up browser would have no barrier to using crypto), and the upgrade to a CA-signed cert, then many more users would clear the hurdles, one after the other. Maybe, maybe not. You've never heard of price inelasticity? The fact of the matter is that we have no real idea how elastic the demand for certs is, and we won't until someone does some real econometrics on the topic. Unless you've done that, you're just speculating. The reason we have no idea how elastic the demand for certs is, is because a) we've never tried it, and b) we've not looked at the data that exists. (Yes, those reasons are contradictory. That's part of the world that we want to change.) It's nothing to do with whether the ivory tower brigade does some econowhatsists on their models and then speculates as to what this all means. Have a look at the data that is available [2]. You will see elasticity. Have a look at the history of a little company called Thawte. There, you will see how elasticity contributed to several hundred millions of buyout money. Mark S prays to the god of elasticity every night. Check out the Utah digsig model. If you can see a better proof of cert elasticity, I'd like to know about it. iang [1] http://www.citi.umich.edu/u/provos/ssh/ http://www.citi.umich.edu/techreports/reports/citi-tr-01-13.pdf [2] http://www.securityspace.com/ http://www.securityspace.com/s_survey/sdata/200308/certca.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ed, I've left your entire email here, because it needs to be re-read several times. Understanding it is key to developing protocols for security. Ed Gerck wrote: Arguments such as we don't want to reduce the fraud level because it would cost more to reduce the fraud than the fraud costs are just a marketing way to say that a fraud has become a sale. Because fraud is an hemorrhage that adds up, while efforts to fix it -- if done correctly -- are mostly an up front cost that is incurred only once. So, to accept fraud debits is to accept that there is also a credit that continuously compensates the debit. Which credit ultimately flows from the customer -- just like in car theft. What you are talking about there is a misalignment of interests. That is, the car manufacturer has no incentive to reduce the theft (by better locks, for e.g.) if each theft results in a replacement sale. Conventionally, this is dealt with by another interested party, the insurer. He arranges for the owner to have more incentive to look after her car. He also publishes ratings and costs for different cars. Eventually, the car maker works out that there is a demand for a car that doesn't incur so many follow-on costs for the owner. This is what we call a free market solution to a problem. The alternative would be some form of intervention into the marketplace, by some well- meaning authority. The problem with the intervention is that it generally fails to arise and align according to the underlying problem. That is, the authority is no such, and puts in place some crock according to his own interests. E.g., ordering all car manufacturers to fit NIST standard locks (as lobbied for by NIST-standard lock makers). Or giving every car owner a free steering lock. And, that's more or less what we have with HTTPS. A security decision by the authority - the early designers - that rides on a specious logical chain with no bearing on the marketplace, and the result being a double block against deployment. (It's interesting to study these twin lock-ins, where two parties are dependant on the other for their mutual protocol. For those interested, the longest running commercial double cartel is about to come crashing down: DeBeers is now threatened by the the advent of gem quality stones for throwaway prices, its grip on the mines and retailers won't last out the decade. Understanding how DeBeers created its twin interlocking cartels is perhaps the best single path to understanding how cartels work.) Some 10 years ago I was officially discussing a national security system to hep prevent car theft. A lawyer representing a large car manufacturer told me that a car stolen is a car sold -- and that's why they did not have much incentive to reduce car theft. Having the car stolen was an acceptable risk for the consumer and a sure revenue for the manufacturer. In fact, a car stolen will need replacement that will be provided by insurance or by the customer working again to buy another car. While the stolen car continues to generate revenue for the manufacturer in service and parts. The acceptable risk concept is an euphemism for that business model that shifts the burden of fraud to the customer, and eventually penalizes us all with its costs. Today, IT security hears the same argument over and over again. For example, the dirty little secret of the credit card industry is that they are very happy with +10% of credit card fraud over the Internet. In fact, if they would reduce fraud to zero today, their revenue would decrease as well as their profits. Correct! You've revealed it. IMHO, not understanding that fact has been at the root cause of more crypto biz failures than almost any other issue. My seat of the pants view is that over a billion was lost in the late eighties on payments ventures alone (I worked for a project that lost about 250 million before it gave up and let itself be swallowed up...). In reality, the finance industry cares little about reducing fraud. This is easy to show, as you've done. There is really no incentive to reduce fraud. On the contrary, keeping the status quo is just fine. This is so mostly because of a slanted use of insurance. Up to a certain level, which is well within the operational boundaries, a fraudulent transaction does not go unpaid through VISA, American Express or Mastercard servers. The transaction is fully paid, with its insurance cost paid by the merchant and, ultimately, by the customer. Thus, the credit card industry has successfully turned fraud into a sale. This is the same attitude reported to me by that car manufacturer representative who said: A car stolen is a car sold. The important lesson here is that whenever we see continued fraud, we must be certain: the defrauded is profiting from it. Because no company will accept a continued loss ithout doing anything to reduce it. It'e perverse, because as you say, the
Re: Is cryptography where security took the wrong branch?
James A. Donald [EMAIL PROTECTED] writes: -- On 7 Sep 2003 at 9:48, Eric Rescorla wrote: It seems to me that your issue is with the authentication model enforced by browsers in the HTTPS context, not with SSL proper. To the extent that trust information is centrally handled, as it is handled by browsers, it will tend to be applied in ways that benefit the state and the central authority. Yeah, I'd noticed that being able to buy stuff at Amazon really didn't benefit me at all. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 09:44 AM 9/7/2003 -0700, Eric Rescorla wrote: Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough. actually was supposedly no worse than the face-to-face world aka make the transit part secure ... so that the rest became the same as the physical world transactions go into big merchant file ... because there are several merchant related business processes that subsequently reference the transaction and number. the problem was that their appear to be little or not fraud associated with threats against CC numbers in flight (with or w/o SSL), however the threat model was against the merchant credit card file and the numbers in the clear; it wasn't that the process was any different than the physical world, but the web merchants allowed the file to be access able from the network (which didn't exist in the physical world). the requirement given the x9a10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments (debit, credit, stored-value, ach, internet, non-internet, point-of-sale, etc). Turns out the internet threat profile wasn't so much data-in-flight but having the operation connected to the internet at all. X9.59 addressed most of that ... which neither ssl or set did and did it with just a single digital signaturee. misc. x9.59 http://www.garlic.com/~lynn/index.html#x959 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
-- At 12:30 PM 9/7/2003 -0700, James A. Donald wrote: To the extent that trust information is centrally handled, as it is handled by browsers, it will tend to be applied in ways that benefit the state and the central authority On 7 Sep 2003 at 17:19, Anne Lynn Wheeler wrote: Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request eliminating all the identification gorp (and also done w/o the use of certificates). I seem to recollect that request, or a request very like it, from some years back. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG HwFde4LnTv0p3hXtAQB7k2SuW04BmKJDrrnyzvRr 4d+oWUHfpousTBWRKiFyUmAecGZRIK1gitZ4NELNp - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Arguments such as we don't want to reduce the fraud level because it would cost more to reduce the fraud than the fraud costs are just a marketing way to say that a fraud has become a sale. Because fraud is an hemorrhage that adds up, while efforts to fix it -- if done correctly -- are mostly an up front cost that is incurred only once. So, to accept fraud debits is to accept that there is also a credit that continuously compensates the debit. Which credit ultimately flows from the customer -- just like in car theft. Some 10 years ago I was officially discussing a national security system to hep prevent car theft. A lawyer representing a large car manufacturer told me that a car stolen is a car sold -- and that's why they did not have much incentive to reduce car theft. Having the car stolen was an acceptable risk for the consumer and a sure revenue for the manufacturer. In fact, a car stolen will need replacement that will be provided by insurance or by the customer working again to buy another car. While the stolen car continues to generate revenue for the manufacturer in service and parts. The acceptable risk concept is an euphemism for that business model that shifts the burden of fraud to the customer, and eventually penalizes us all with its costs. Today, IT security hears the same argument over and over again. For example, the dirty little secret of the credit card industry is that they are very happy with +10% of credit card fraud over the Internet. In fact, if they would reduce fraud to zero today, their revenue would decrease as well as their profits. There is really no incentive to reduce fraud. On the contrary, keeping the status quo is just fine. This is so mostly because of a slanted use of insurance. Up to a certain level, which is well within the operational boundaries, a fraudulent transaction does not go unpaid through VISA, American Express or Mastercard servers. The transaction is fully paid, with its insurance cost paid by the merchant and, ultimately, by the customer. Thus, the credit card industry has successfully turned fraud into a sale. This is the same attitude reported to me by that car manufacturer representative who said: A car stolen is a car sold. The important lesson here is that whenever we see continued fraud, we must be certain: the defrauded is profiting from it. Because no company will accept a continued loss ithout doing anything to reduce it. What is to blame? Not only the shortsighted ethics behind this attitude but also that security school of thought which is based on risk, surveillance and insurance as security tools. There is no consideration of what trust is or means, no consideration whether it is ethically justifiable. A fraud is a sale is the only outcome possible from using such methods. The solution is to consider the concept of trust(*) and provide means to induce trust among the dialogue parties, so that the protocol can be not only correct but also effective. The problem I see with the protocols such as 3D Secure (for example) is that it does not allow trust to be represented -- even though it allows authorization to be represented (**). Cheers, Ed Gerck (*) BTW, I often see comments that it is difficult to use the concept of trust. Indeed, and unless the concept of trust in communication systems is well- defined, it really does not make sense to apply it. The definition that I use is that trust is that which is essential to a communication channel but cannot be transferred through that same channel. This definition allows one to use Shannon's communication theory formalism and define trust without any reference to emotions, feelings or other hard to define concepts. (**) Trust is often used as a synonym for authorization (see InterTrust usage, for example). This may work where a trusted user is a user authorized by management to use some resources. But it does not work across trust boundaries. Trust is more than authorization. Ian Grigg wrote: This is mostly prevalent on the Internet, where there is a sense of self-taught, non- commercial application of cryptography. My time in (or close to) a telco taught me the difference, as there, they have an engineering focus on cryptography, and really understand what it means to calculate the cost of the solution. For them, leaving a weakness was just another risk calculation, whereas so much stuff that happens on the net starts from we must protect against everything and then proceeds to design the set of everything for ones convenience. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
In message [EMAIL PROTECTED], Ian Grigg [EMAIL PROTECTED] wrote: For example, he states that 28% of wireless networks use WEP, and 1% of web servers use SSL, but doesn't explain why SSL is a success and WEP is a failure :-) Actually, he does; slide 11 is titled Why has SSL succeeded?, and slide 23 is titled The WEP Debacle. Also, although speakers often do nothing more than read what's on the screen, a talk does ideally involve more content than is on the slides. I would agree that HTTPS has been more successful than WEP, in the sense of providing defense against real threats. HTTPS actually defends against some real attacks, providing an effective answer to a clearly defined problem: preventing the exposure of sensitive information such as credit card numbers, even in the face of eavesdropping and server impersonation. This is only one threat model and maybe not the most realistic one, but HTTPS does define it and address it. Meanwhile, WEP is too weak to prevent any attacks; and even if it were not cryptographically weak, its stone-age key management would make it a poor tool for any network with more than a handful of users. A very relevant question is why WEP has been so much more widely deployed than HTTPS. Eric Rescorla is correct that people choose whether to use security measures or not based mostly on how convenient they are, not on how much they need them. In this sense, HTTPS is a failure; although it is effective, it is so difficult to use that almost no one bothers unless credit card numbers are involved. Security needs to be easy, or people will just put up with losses instead. One thing he doesn't stress is design by committee v. design by small focused team. Much of SSL and SSH's strengths are that they were designed and deployed quickly and cheaply (and insecurely!) so as to tap into real needs real quickly. I would suggest that any security protocol designed by a committee has a low survivability rating. In fact, early versions of both SSL and SSH had extensive flaws; it took many people to evolve them into their present states. *All* security protocols have low survivability ratings. Inventing a new protocol is extremely hazardous. -- Shields. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg [EMAIL PROTECTED] writes: There appear to be a number of metrics that have been suggested: a. nunber of design wins b. penetration into equivalent unprotected market c. number of actual attacks defeated d. subjective good at the application level e. worthless measures such as deployed copies, amount of traffic protected You forgot the most important one: f. value added elsewhere SSL's real strength is that it's convinced 100 million Joe Sixpacks that it's safe to make purchases online. This has nothing to do with security (you could do the same with padlock GIFs stuck on your web page), but does count as some sort of measure of success, although it's marketing success rather than security success. Although they provide about the same level of real security, it seems that SSH is the tool of choice for people who care about providing real security while SSL is the tool of choice for people who care about providing their customers warm fuzzies. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg [EMAIL PROTECTED] writes: Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: I think it's pretty inarguable that SSL is a big success. One thing that has been on my mind lately is how to define success of a crypto protocol. I.e., how to take your thoughts, and my thoughts, which differ, and bring the two together. There appear to be a number of metrics that have been suggested: a. nunber of design wins b. penetration into equivalent unprotected market c. number of actual attacks defeated d. subjective good at the application level e. worthless measures such as deployed copies, amount of traffic protected All of these have their weaknesses, of course. It may be that a composite measure is required to define success. I'm sure there are more measures. a. The only thing that seems to be clearly a win for SSL is the number of design wins - quite high. That is, it would appear that when someone is doing a new channel security application, the starting point is to consider SSL. b. we seem to be agreeing on 1% penetration of the market, at least by server measurement (see my other post where I upped that to 1.24% in the most recent figures). This really depends on your definition of market. SSL was designed to protect credit card transactions, period. For that, the market penetration is near 100%. d. subjective good. For HTTPS, again, it's a decidedly mixed score card. When I go shopping at Amazon, it makes little difference to me, because the loss of info doesn't effect me as much as it might - $50 limit on liability. That $50 limit is a funny thing. I look at it this way: You don't PERSONALLY eat the cost of fraud on your own card but you eat the cost of fraud on other people's cards. Thus, as in many situations, it's in your interest for everyone else to practice good hygiene. In this particular case, the issuers were *very* wary of providing credit card transactions over the Internet without some sort of encryption. So, SSL is what enables you to do e-commerce on the net. That seems like a large subjective good. Actually, I think that SSL has the right model for the application it's intended for. SSH has the right model for the application it was intended for. Horses for courses. Plenty of room for future discussion then :-) (I sense your pain though - I see from the SHTTP experiences, you've been through the mill. Vis a vis SHTTP, I'm not sure if that was the right design or SSL was. However, they had relatively similar threat models. I'm almost convinced that WEP is a failure, but I think it retains some residual value. I agree. After all, I occasionally come upon a network I'd like to use and WEP stops me cause I'm too lazy. On the other hand, MAC restrictions would have done just as well for that. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
In message [EMAIL PROTECTED], Ian Grigg [EMAIL PROTECTED] wrote: One thing that has been on my mind lately is how to define success of a crypto protocol. There are two needs a security protocol can address. One is the need to prevent or mitigate real attacks; the other is to make people feel less afraid. HTTPS might or might not have addressed a major problem, but it did address a major fear. Many people -- not only consumers, but also merchants, issuing banks, and processing companies -- were concerned about using credit card numbers on the Internet in 1995, when there was no viable way to buy anything online. Netscape designed an effective protocol, deployed it widely, and made it visible to end-users. It offered a credible promise that you could trust your session without trusting the network, and that's what made people willing to do large-scale online commerce and banking. This is not to be underestimated. At the same time, Netscape put visible crypto into the hands of people who had never used crypto before, and in many cases had never even owned a computer before. This did a great deal to counter the rhetoric about encryption being a tool for drug dealers and child pornographers. The physical security industry has known for a long time that if you want something deployed, you shouldn't be looking at what problems are interesting or even at what problems people actually have. You should be looking at what makes people afraid. Fear drives deployment. -- Shields. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
