[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyNote draft available
Bill Frantz writes:
> At 1:10 PM -0800 3/14/98, E. Gerck wrote:
> >Bill Frantz writes:
> > > At 10:56 AM -0800 3/14/98, E. Gerck wrote:
> > > >You recognize of course that this "argument" is seriously deceptive:
> > > >if we cooperate with a security flaw because it is inevitable for
> > > >set = A and make it the freely avaliable for set = Universe then
> > > >unless A = Universe we have effectively reduced the security level.
> > >
> > > Is it better to deliver systems which claim to enforce things they can not
> > > enforce, or to deliver systems that do not make those claims?
> > >
> > > IMHO, In the former case, people will trust the claims and field insecure
> > > systems. In the latter case, people will understand the limits of
> > > technology and include non-technological controls.
> > >
> >Certificates are machine-readable statements and deal with claims
> >which can either be proved or disproved by Turing machines. To that
> >precise technical constraint we must add the social use (or, abuse) of
> >certificates. However, to claim that the social (ab)use negates the
> >usefulness of strong technical barriers in certificates is an
> >exaggeration. "Law is no substitute for engineering" applies here also
> >and it is a common high-school experience that a cheap $1.00 lock that
> >anyone could break affords much more privacy than a "DO NOT OPEN" sign,
> >in a locker-room.
> Hi Ed,
> Of course. The lock offers an audit trail. (If the lock is broken, then
> someone has broken in.) It also increases the risk of getting caught in a
> way that sharing keys does not. The basic problem is that the "strong
> technical barriers" are so weak that they are bypassed every day.
You are right in poiting out about the adudit trail if the lock is
physically broken and that provides a further example for the
advantage of not relying only on a "DO NOT OPEN" signal, ie, a
social barrier. However, it mixes up both controls (social and technical).
However, that was not what I was targeting (sorry for the lack of
context clarity there). When I wrote "cheap $1.00 lock" I was
targeting a lock that could be easily picked -- as it often happens
in high-school locker-rooms -- exactly so an audit traill is not
present. In this case (non-physical) it can be seen that a very
simple technical barrier is a stronger deterrent than a social
barrier. This example is better in the sense that it does not
mix social with technical barriers (as the broken locker does).
I think that Nick was very fortunate to bring the term
"admonition" policy to this discussion in the sense that it emphasizes
that a security policy that depends on social values (ie, law, custom,
friendship, rules, etc.) is actually not directly enforceable -- it
not only depends on a perfect feedback loop (anyone can get caught) but
is also NEVER deterministic (you will NOT always get caught).
Of course, if one can (by collusion or by cleverness) render the
feedback loop inoperative (eg, mafia) then it is also not enforceable
in a pragmatic sense -- even though the culprit may be admonishable or
Thus, when security depends on admonition it depends on social,
subjective and probabilistic factors. So, its appraisal strongly
depends on the observer while its effectiveness strongly depends on
To contrast, when security depends on a strong technical barrier,
one is able to objectively assess its usefullness as a function of the
S, C, X, Y, A, B, T parameters of my former e-mail. Some of them may
be probabilistic but the security level reached can be judged equally
well by any any observer and can be equally well enforced for any
> As a real-world example. When I first got my Netcom account, their use
> policy did not allow account sharing. I suspect that this policy was
> widely ignored. Their current policies specifically recognize account
> sharing, an accommodation to the realities of the world.
> I now share access to my Netcom account with my wife. I do not share
> access to accounts I get through my work with her. However, there are no
> technical barriers preventing me from doing so. The only barriers are
> legal and ethical.
... and auditing trails, which can compare login times from different
sources, work schedule and so on. These are strong technical barriers
because they are controlled by the sysadmin and unless you have the
root password or a collusion with the sysadmin you cannot circunvent
that. This is similar to the broken locker case, IMO, where you have a
mixture of both cases.
> >For example, X.509v3 uses the critical bit construct for
> >several purposes but also in order to achieve delegation control, in a
> >meaningful way, which shows that it is not only possible but also
> One specific question about the X.509v3 critical bit. How does it prevent
> me from giving my smart card and it's access codes to my wife?
Eaach tool has its domain of use and one may have all sorts of
different nails. The fact that X.509 does not cover all nails does
not mean that it does not hammer in the nails it was designed to
handle. In other words, as my first msg on this topic, if you
can restrict the problems to set = A then you are doing a better
job then not restricting anything -- which effectively makes
A = Universe (in set theory).
> >Regarding enforceable or unforceable things, I disagree that such can
> >have the absolute measure explict in your statement "systems which
> >claim to enforce things". Clearly, "enforcing something" is not only
> >a matter of degree but also depends on the proposition's environment,
> >goals, actors, time, etc.
> Certainly. That is precisely my position. You must include the human
> element as part of the environment for any system you design.
Yes, we are in perfect agreement on this,, but that can be
(to an extent) quantified and included in the picture -- which is
better (that was my point) than leaving it 100% open. Even a cheap
$1.00 lock that anyone can pick could offer a better protection than a
NOT sign -- after all, car locks prove that all the time.
> Ed. I look forward to seeing your specific objections to the points made at:
> http://crit.org/http://www.caplet.com/security/taxonomy/ through the Crit
> system (http://www.crit.org).
Yes, I will. The central backbone from the University here was down
due to a tropical storm and only now I can go do it, so I can't comment
Dr.rer.nat. E. Gerck email@example.com
--- Visit the Meta-Certificate Group at http://www.mcg.org.br ---