That reminds me of the Media Lab idea that binary choices are bad and things should be specified as a range.
What we are doing here is attempting to reduce risk and risk is a continuous variable. In the simplest model of risk we merely consider if there is a non negligible probability of a loss. In the next model of risk we might multiply the probability of a loss occurring by the probable loss. That is not completely accurate either since there is a range of probable loss and a probability associated with each one and so we might need to consider them as continuous functions And even that does not capture everything as large losses are more catastrophic than small ones. The last seems to be what tripped up the financial markets. A 1% risk of losing 100 billion is a loss of $1 billion on average. But nobody can carry the insurance for a loss that size so when that 1% comes up it is going to take down the whole system with it. A useful definition of 'trust' is the ability to accurately quantify risk. In this definition, saying a party or an application or a platform is trusted means no more than that I am exposed to risk should it default and trustworthy means no more than that the degree of residual risk is known to be within acceptable bounds. On Thu, Jan 26, 2012 at 8:56 PM, Martin Millnert <[email protected]> wrote: > On Thu, 2012-01-26 at 14:10 -0800, Chris Palmer wrote: >> On Thu, Jan 26, 2012 at 1:43 PM, David Conrad <[email protected]> wrote: >> >> > I'm curious: where do you draw the line? Should routing system security >> > be included? Email security (since many transactions relating to DNS zone >> > administration occur via email)? Telephone? Etc. >> > >> > Security that looks at 'all possible sources of error' seems to me to be a >> > halting state problem >> >> As security engineers, our role is to (a) reduce the number of >> entities we trust; (b) reduce the extent to which we trust the >> remaining trusted entities; and (c) determine the trustworthiness of >> trusted entities. > > I'm trying to fit the trust mobility ideas behind Convergence into this > picture, plus, the mentions on this list of having a non-boolean > definition of trust/no-trust - which I found quite interesting. > > Guess they're all c) in this case? > >> This list is about, "We can do better at those three things." That's >> hardly saying, "Let's solve the halting problem." >> >> Having certificates or public keys in the first place are great at >> doing (a), when they work. For example, if you know you've got the >> right key, you no longer need to trust DNS or BGP or TCP. CAs are an >> attempt to do (c). The proposals that this list is to discuss are >> further attempts to do (c) — even if, perhaps, the email system is >> compromised. > > Drilling down a little, what about: > s/if you know you've got the right key/if you are 87% sure you've got > the right key/ ? > > Intuitively(*) to me, having a way of offering a non-boolean (sum of) > trust to a user will have us end up with a system capable of offering > more total security than one without. > > * I'm drawing intuition from Linear Programming optimizations vs Integer > Linear Programming optimizations, where boolean total trust corresponds > to ILP, which normally is harder to solve than LP. I'm not sure how my > cerebrum made this immediate association. > > >> So, yes, all those things are and should be in scope. >> >> By contrast, some things are clearly out of scope, such as host >> integrity. (Other efforts are working on that problem, and they can >> indeed succeed at incremental improvements in (a), (b), and (c) >> without exploding to become the halting problem.) >> _______________________________________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
