Julien Pierre wrote: >> Back to Ian's comments on market value... if all you risk is $50 a year >> in credit card fees, $40 is well worth the money, $900 isn't... > > That's a false premise, though. Even though it's one of the most popular > applications, SSL is used for much more than online credit card > transactions, but also for many more transactions which do not have the > same legal protections as credit cards do in the US, including stock > trading, electronic check transactions, wire transfers, etc. For many of > these transactions, the authentication is crucial, as you may not have > any recourse if something goes wrong with your confidential data.
Julien, Let's see if we can tease out that false premise. I'd say the false premise is that the protection in HTTPS be set for everyone at the same level, as required to protect the highest value of transaction for some small set of people. Firstly, we do not know what the users are doing. We don't know which user is doing what value transaction, or when, or how it is related to any other activity. Secondly, we do not know which transaction to target and thus protect. We don't know its value, the attacks facing it, costs of those attacks, whether identity matters or not, what regulation or rules applies... Thirdly, we do not know whether we can stick with one transaction set, or whether we are trying to cover all transaction sets. I.e., it is a fact that nominally, SSL was required/invented in order to protect credit card transactions. Yet, it is also a fact that the SSL model is singularly unsuited to that role (c.f., SET), and that what was built instead was a general purpose connection security protocol for client-server channels. E.g., within the life of the design of the protocol, not to mention its implementation, the original transaction requirement was disposed of, and something different was built. (Whether this was good or bad is not debated here, but the point is that SSL is not really tuned to the task of protecting credit card transactions, something that many people in the credit card world will be happy to discuss at length.....) In short, we do not know anything about what the transactional usage that we might be trying to protect. So, setting the protection at the highest level MUST BE A MISTAKE, because we cannot decide on what that highest level might be. In fact, we have no tools whatsoever to decide *any* level, nor practically anything about the transactions. Which is how it should be. The users should decide what protection they need and what they can afford (by this I mean server users and browser users). Funnily enough, they know much much more than any security developer about their own risks. The only problem is that HTTPS *denies* them the capability to set their own protection. Or, as I recently ranted, they have a binary choice: Servers can do only high end purchased CA certs, or nothing, and browser users can only do whatever the server has decided to do, "nothing" or "everything." Under these conditions, it is unreasonable to suggest that we are trying to protect "high value." It's also wrong, in point of fact, to suggest that HTTPS does protect the value of serious transactions. For example, hard or high value, say, RTGS payments systems, those with no recourse (gold payments, or smart cards), have to spend a lot of money protecting their transactions with add-ons to the security model. The have to do this because the security that comes with browsing is only worthwhile up to maybe $100 or so and maybe 1000 users. And that's being kind. Many institutions expect to deal with transfers of higher than that. If they have the unfortunate characteristic of *relying* on those transactions, (many banks in the US and other places have to do rollbacks of value when they get hit, which means they are not included here, they are not relying totally on the security of the browser) then they need to do things like send out challenge/response hardware, add in fraud detection software, write turing tests, send two part transaction confirms, etc etc (every DGC does something different). In fact, those sites that really really need protection would be happy with 40bit crypto and a self-signed cert if they could just get the users to click on a browser button to create their own client cert. Now, *that* would allow them to develop a relationship that could be protected by a client-side authentication, instead of dealing with this whole phishing and password crunching and merchant hacking stuff that they have to deal with. That would be protecting users! Instead, they have to pay money to other places and for other techniques to protect their users. iang PS: Oh, well, I suppose there is one thing that we know: the users tend to do their transactions with a site that they are familiar with (banks, transfer agents (paypal, goldmoney), auction houses, etc etc). Funny thing, one of the requirements for SSL was that it protect transactions where the user had no prior relationship, which happens to be an unusual transaction - I mean, who just clicks on a URL and starts filling out a form with their credit card details without doing some checking??? - and not the common transaction that we normally see needing protecting. It is not explained why this is for SSL, just assumed. Just another false premise. _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
