Tim Dierks wrote: > > At 12:28 AM 10/13/2003, Ian Grigg wrote: > >Problem is, it's also wrong. The end systems > >are not secure, and the comms in the middle is > >actually remarkably safe. > > I think this is an interesting, insightful analysis, but I also think it's > drawing a stronger contrast between the real world and the Internet threat > model than is warranted. > > It's true that a large number of machines are compromised, but they were > generally compromised by malicious communications that came over the > network. If correctly implemented systems had protected these machines from > untrustworthy Internet data, they wouldn't have been compromised.
The point is, any compromise of any system is more likely to come from a node compromise than a wire compromise. How much more likely? We don't know for sure, but I'd say it is in the many thousand times as much. E.g., look at those statistics. Basically, the wire threat is unmeasurable - there are no stats that I've ever seen, and the node compromise is subject of some great scrutiny, not to mention 13,000 odd Linux reinstalls every month. Does it mean that we should ignore the wire threat? No, but it does mean that we are foolish to let any protection of the wire threat cause us any grief. Protecting against any wire attack is fun, but no more than that - if it costs us a dime, it needs to be justified, and that is really hard given that we are thousands of times more likely to see a compromise on the node. If we spend 10c protecting against the wire attack, should we then spend $1,300 spending against the node attack? The situation is so ludicrously unbalanced, that if one really wanted to be serious about this issue, instead of dismissing certs out of hand (which would be the engineering approach c.f., SSH), one would run ADH across the net and wait to see what happened. Or, spit credit cards in open HTTP, and check how many were tried by credit card snafflers. You might be waiting a long time :-) But, that would be a serious way for credit card companies to measure whether they care one iota about certs or even crypto at all. > Similarly, the statement is true at large (many systems are compromised), > but not necessarily true in the small (I'm fairly confident that my SSL > endpoints are not compromised). This means that the threat model is valid > for individuals who take care to make sure that they comply with its > assumptions, even if it may be less valid for the Internet at large. If the threat model is valid for individuals who happen to understand what all this means, then by all means they should use the resultant security model. I don't think that anyone is saying that people can't use SSL in its current recommended form. JUst that more people would use SSL if software didn't push them in the direction of using overly fraught security levels. > And it's true that we define the threat model to be as large as the problem > we know how to solve: we protect against the things we know how to protect > against, and don't address problems at this level that we don't know how to > protect against at this level. (See my first reply to Erik, where I quoted two sections, earlier today.) We protect against things which are cost-effective to protect against. That is, we use risk analysis to work out the costs v. the benefits. We know how to protect against an awful lot. We simply don't, unless the cost is less than the benefit, in general. And, this is the point: SSL protected against the MITM because it could. Not because it was present as a threat, and not because it was cost- effective. It was infamously and deplorably weak security logic; what it should do is protect against things that are a threat, and for a cost that matches the threat. > So, I disagree: I don't think that the SSL model is wrong: it's the right > model for the component of the full problem it looks to address. And I > don't think that the Internet threat model has failed to address the > problem of host compromise: the fact is that these host compromises > resulted, in part, from the failure of operating systems and other software > to adequately protect against threats described in the Internet threat > model: namely, that data coming in over the network cannot be trusted. > > That doesn't change the fact that we should worry about the risk in > practice that those assumptions of endpoint security will not hold. It's about relative risks - I'm not saying that SSL should protect the node. What I'm saying is that it is ludicrous to worry overly much the risk that SSL deals with - the ITM, supposedly - in most practical environments, because that's not where the trouble lies. Another Analogy: Soldiers don't carry umbrellas into battle. But it does rain! The reasoning is simple - unless the umbrella is *free* it's ludicrous to worry about water when someone is shooting bullets at you. We do a risk-analysis on the umbrella, and we discover that it has a cost of making us too conspicuous. Cost exceed benefit, we ditch the umbrella. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
