On Thu, 2012-01-26 at 14:10 -0800, Chris Palmer wrote: > On Thu, Jan 26, 2012 at 1:43 PM, David Conrad <d...@virtualized.org> 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 > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey
signature.asc
Description: This is a digitally signed message part
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
