> Most of the info that travels the net needs no "protection". Its > value is SO LITTLE that no-one would spend a penny to collect it. > We shouldn't be concerned that that info is not encrypted.
This is an error. The people who use the net are the ones who should get to decide whether their traffic should be encrypted, not us techies. Otherwise, we'd all agree that 640K is enough for anyone. > Most users have a pretty good idea of what they want protected, and > what information they have that needs protection. Often, yes. They don't get to exercise choice in this, much. Server users will exercise it, but only if they are prepared to go the distance to pay for the cert (I know, I'd like to use a cert on my personal web site, but it's not worth it to go through the hundreds of dollars of cash and of effort, and to upgrade this service or that config). > They don't care > about the lock when they go read the daily news, or the daily porn > (:-), A lot of people *do* want to do that, if they are reading the daily porn from work. Now we may decide that we are not going to protect those people ... but, that means we are playing God, and it definately doesn't match our agreed goal of protecting the users. > but when they go to their bank, or pay bills online, they want > protection. And, they don't get it: they only get what the bank provides. Instead they should be able to get protection across all the forms, not just the ones the banks have turned to "on" because that's what they configured on the day. > They want to know that they're sharing that info only > with the bank, or the specific party to whom they've previously > decided to entrust that information. Some of them would also like > protection of confidential email, but most do not even realize that > such capabilities exist. Well, isn't it odd that a browser hasn't got a button to initiate a crypto session? Why is that? Why does the *server* get to decide? Why is it that the server has to request a client side cert, and not the client profer it? I don't think the user - the user of the browser that is - has any choice in the matter at all! In Mozilla's terms, the user is not protected by choice of Mozilla, but by choice of the server. Users get what they're given, and it's pretty poor fare at that. But, to change that would require quite serious changes to the SSL protocol, and all we are suggesting here is some minor tweaks at the application layer, not to the protocol at all, and not to the certificate infrastructure. > The measure of crypto success is what percentage of the time they > get protection for that traffic that they want protected. That > protection means more than encryption. It means assuring that the > encrypted traffic ends up in the hands of the right (authenticated) > party at the other end, the one to whom they've chosen to entrust > their data. No, not at all. That's potentially *one* of the goals of any system, but it needs to be validated, and it needs to be required by the application. It also needs to be economic. In practical terms, authenticity is a stated goal of SSL requirements, but it not necessarily required by the application, nor is it validated by the threat level. Cryptographers are fairly clear on this, at least. There needs to be a set of application requirements, and a threat model. (Both of those were questionable in the specific case of HTTPS.) Then, a security model needs to be constructed. In the case of HTTPS, it was perhaps done backwards, it was done in haste, and a fairly reasonable protocol was constructed (SSL) and put into a fairly bad security model. As the threat level was rather low until 2002 or so, it wasn't an issue, and it had a very significant placebo effect, so it was welcomed, especially by those who found something to sell. But, its security value is highly overstated, due primarily to flaws in its starting assumptions. > So, the objective here is NOT to drive the percentage of encrypted > traffic to 100%. It is to ensure that the data worth protecting > (as judged by the holders of that data) is protected, that is, is > communicated only between the user and the chosen and authenticated > remote party. It is really tough coming up with an objective. Firstly, you don't know who or what the users are doing. And, we have already left behind the browser users in SSL, as they can't change what Amazon does. On your average website (not sure about Amazon?), a user of Mozilla cannot, for example, chose crypto to enter their reviews into the Adult section, so their teenage children can't see what's happening over the unprotected 802.11b. All we can really do is help server operators to use more crypto, and ease them towards employing better authentication and better certs, over time. In terms of protecting users - Mozilla's goals - about the only avenue left that's easy is opening up the cert usage to more servers. (Oh, and we need to address the phishing. Either it's done here or it will be done somewhere else....) > Encryption without authentication is worthless. It's false security. > Getting everyone to use SSL, without meaningful authentication of > at least one of the peers, is worthless. I'm sorry, I don't agree. This is what people thought in the mid 90s. Since then, there has been a *lot* more thought put into crypto, and also a *lot* more empirical experience. Many of the fallacies underlying the original models have been identified and exorcised. Just to point out one fallacy, that which we might call "no-risk cryptography:" In the 90's the notion was to create a protocol that dealt with all known risks (of which SSL was the best example, but PGP also followed this goal). But, as time went on, it became clear that this was simply too expensive, so what occurred was that many many opportunities ended up being totally unprotected. Since then, it has been re-discovered by Internet crypto people that that the more economic model makes more sense: risk and return (which was always what was used in the non-Internet security field). That is, employ the amount of security that one can afford, and cover those risks that can be done so economically. Bruce Schneier, for example, wrote a public recanting of the no-risk crypto approach in his big red book, in 1999 or 2000 or so, when he realised that it was fatally flawed. His later books have reflected the economic model. > If CPUs were free, and certs were free (due to absense of costly > identity verification), and all http servers became https servers, > (but with no greater assurances of the peer's identity than http gives > today) web users would have no more security than they have today, and > probably less. Hugely more. To breach a self-signed cert protected session, one has to conduct an MITM. This is tricky, and can only be done in some places, with some risks. Further, one has to do it at the first cert passage, so if there is proper cert caching in place, there is only one vulnerable moment, which is rather hard to pick in advance. I.e., you have to be there, in advance, and you have to suck up all, MITM all, or know your target is coming. SSH is the most successful Interenet crypto protocol in existence, in market terms. It has walloped the competition, both telnet and secure telnet. People who switch to SSH from other products never go back. Yet, it does it all with self-signed certs (free!) and caching (free!). > The lock would then be truly meaningless. It would be closed all the > time, and users would have NO reason to trust their browser's connection > with their bank any more than its connection with any criminal enterprise. > The lock has to sometimes appear unlocked in order for there to be any > value to it ever appering locked. Well, that's what all the discussion about the chrome branding area is all about. The lock is already verging on meaningless, and needs to be replaced regardless. > Strong authentication remains > crucial to the encryption having any protective value. That's simply not the case. It's possible to knock out all simple listening attacks with ADH, and no authentication. Why would the Internet throw that benefit away? It's totally free, and it has no down side over the nearest alternate - HTTP. And, cached self-signed certs get you even more, for just as free! > The cost of certs is the BIG major drawback to the deployment of > SSL, right? One of them. Also, the configuration of the servers, they should generate self-signs on install. And, the browsers should not warn about the use of crypto. And, the certs should be branded, so that users can enter the loop and decide for themselves what is worth risking. > In the 8 years I've worked on SSL, that has never been > the finding of any of the market research firms that periodically > examine questions like that. OK. Did those market research firms predict the stock price of Verisign? Or Baltimore? The highs? The lows? Did they predict that PKI as a separate sector would die the death it is now in? Who did they ask whether an SSL cert was too expensive? Someone who had already put one in place (!) or someone who hadn't (!!!) or someone who'd tried and given up in disgust? I hope nobody here paid any money for the product of those market research firms :-) Who did they sell their reports to anyway? People building and selling SSL stuff, I'll bet. > SSL continues to be unpopular in large part due to the cost of the > additional "iron" needed to do it. https servers do only a fraction > of the pages/second that http servers do. > > At one time, it was considered "common knowledge" among IT types that > an https server did 1/7 of the throughput of a comparable http server, > which meant that it took 7 times as much hardware to accomplish the > same throughput. THAT's the big cost of SSL, not the cost of certs. Nah, this is all old wives tales. The sector you are talking about is "big iron sites." Of the 10-20 million web sites out there, there are maybe 100,000 big sites that care about server performance. Who cares about them? They have enough money to deal it themselves (if, and I don't believe it is, this is a problem at all). It's the rest of the world that needs help. [developer thread snipped for brevity...] > Similarly, allowing the browser to honor certs from CAs that do not > take adequate (or ANY) measures to ensure the identity of the parties > to whom they issue certificates may provide immediate user gratification, > but does not ultimately lead to user security. Why then would we permit the browsers to honour requests for totally unprotected HTTP then? iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
