The way I was taught to do security analysis is you start off with everything on the table and look to identify all possible sources of risk. You do that by identifying assets, the risks against those assets etc. etc. It is an iterative process and it is frequently useful to work in both directions, since considering attacks and generalizing them to threats often identifies risks and often assets that you might not otherwise have realized were involved.
At the end of the process you then consider relative importance of the risks, there are to issues here, one is the probability of the risk being realized, the other is the consequence. Here we are dealing with a set of risks that were very low probability when the serious attacks were mostly motivated by money. Now the observed incidence of those attacks is going up and the motive is often political so raising the cost of the attack does not necessarily provide a deterrent. This is an objective process. There is no risk of 'philosophy'. Here we have people who are saying that one threat 'is' out of scope (wrong see below) despite a very high observed incidence rate when another threat realizing the same risk is of paramount importance despite a negligible incidence rate. If people want to talk about the scope of this list, they should first read the proposal I wrote when I requested it be created. Stephen appended it to the announcement. It is one thing for people to argue what the scope SHOULD be. But I know what I wrote. On Thu, Jan 26, 2012 at 6:56 PM, Martin Rex <[email protected]> wrote: > David Conrad wrote: >> >> On Jan 26, 2012, at 1:52 PM, Martin Rex wrote: >> >> Security that looks at 'all possible sources of error' seems to me >> >> to be a halting state problem >> >> > Drawing a line amounts to sticking your head in the sand. >> >> Or a realization that it isn't realistic to try to solve >> "all possible sources of error". > > If a secure identity system existed, we would be using it. > > If a secure identity system could be invented, it would have been > invented by now. > > So far, the best known approach is to look at *all* parts of the > system individually, and perform risk management for it, > i.e. ensure that the cost of breaking it is sufficiently high > that the entire system amounts to a good-enough trade-off. > > >> >> > If we believe >> > that using DNS names for authentication, then we need to fix *all* >> > parts of the technology, including the adminitrative procedures >> > for managing/delegating DNS names. >> >> That isn't even close to "all possible sources of error". >> >> You would seem to draw the line at "administrative procedures for >> managing/delegating DNS names" (if DNS is to be used). > > The line in the above statement is the circle aroud "*all* parts", > which leaves no parts of the system on the other side of that line. > > But "fix" may have been misleading here. It was meant in the sense > from above: ensuring for each part individually that the cost of > breaking it is high enough that the resulting system amounts > to a good-enough trade-off. > > > The EV-certs approach is in principle correct: those who want the > extra trustworthiness should bear the additional costs necessary to > ensure that trustworthiness. > > > -Martin -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
