Eric Rescorla wrote: > > 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.
We do have the problem that SSL can be considered to be a channel security product, or it can be considered to be a credit card protection product. Part of the problem lies in the switching of arguments from one purpose to another. If one criticises the credit card aspects, the answer is often that SSL is a channel security product. And v.v. The result is slippery, and it can only be done so many times before one gains the impression that SSL is snake oil and the real needs are elsewhere. We need to decide. If SSL is aimed at credit cards, and HTTPS is only present for credit cards, then why is it that OpenSSL spends so much time on it? What's their incentive? I'm not sure I understand why Eric and Tim and Ben and whoever does it these days spend huge amounts of unpaid time developing code so that other people could protect ... the credit card issuers' risks? And, isn't it about time we designed a new product to protect against the threats that users face today? One that could be used by the rest of us? I think it's fair to say that SSL was designed because of credit cards. But now, SSL/TLS is for the purpose of a channel security requirement. The credit card thing is a forgotten issue, SSL can be used to protect credit cards, but the protection of credit cards no longer has anything to do with the way SSL/TLS is designed, tested, measured or implemented. To rest any current requirements on credit cards means that SSL should be oriented towards the threat to credit cards, and it plainly isn't. 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.) Having said all that, maybe we need to add to the list of "market success measures" a part on success at original target, and applicability for other missions? > For that, the market penetration is near 100%. (OK. My guess there would be well above 50%, probably around 90%, by servers, of those taking credit cards. I spent a little time googling, and found about 10% of credit card sites had open forms. I've also seen a fair amount of anecdotal evidence that suggests that any merchant who's less than 100k of revenue probably won't be worrying too much about secured delivery of credit cards. Probably in terms of number of transactions and total value dealt with, the coverage is right up there above 99%...) > > 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. Yup! It is an extraordinarily interesting thing from an economics pov. It's a piece of market interventionism that pleases few, except the marketing folks that admire its beauty, or the economists who admire its subsidy. > 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. Right. That might be a good argument if the issuers of credit cards practiced good hygiene. But, in practice, they don't. What they practice is risk management. That is, they figure out what the fraud rate is, and charge percentages and penalties according to the sector. The issuers - the people that the browser and server people are working so hard to protect - couldn't give a flying f**k if the user has breached hygiene. What they are concerned about is that the costs are covered by fees. And, perversely, a little known finance secret, the system works best if the fees are stabilised at a high level. See above, $50. 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.") It's all well and good that users are encouraged to practice hygiene. But, users should practice risk management first. Hygiene second. In this case, the merchant - a user - should be allowed to calculate his risks. With HTTPS, he is denied that opportunity. (We all know where this is heading ...:-) 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. As if anyone cares about that ;) > 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. Right. They had this fallacious threat model. And what solved it - in their minds - was the application of some crypto. SSL as a placebo. I grant, that may well be the crowning reason for SSL's success. (One can see this when one considers the case for 40 bit crypto. That would have done perfectly for protecting credit cards. But, because of the absence of a threat model, there was also absence of requirements. So 40 bits, instead of being entirely adequate to protect credit cards, became entirely inadequate.) Fair enough, as long as we understand their motives at the time. That all was nearly 10 years ago. (I'm not sure I as an individual would have been able to see the full story then. It's important to realise that the net was younger then, and the full impact of the commercial steamroller was only imagined at by most of us.) But, it's now a decade down the path, and its well time to re-assess whether SSL/HTTPS, etc, is using the right models to benefit us. Or anybody, really. > > > 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. hmm. Are you saying that SHTTP didn't have a threat model (one interpretation of your "Hickman" post) or that SHTTP assumed the Internet Threat Model (ITM) in the same way that SSL did? > > 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. That seems to be close to the truth of it. About the only thing that is stopping one from cracking WEP other than laziness is the fact that one is knowingly and deliberately breaking into a network (no matter how weakly secured). YMMV as to what sort of an impediment that is, I don't think it is much to write home about on a crypto scale. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]