Design criteria, was Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Ed Gerck <egerck@xxxxxxx>]

tgindin@us.ibm.com wrote:

> Ed Gerck <egerck@nma.com> on 07/22/99 02:45:21 PM wrote:
>
> What I am saying is not that passwords are "better" than certificates -- such
> comparison would be even senseless. But, simply, that adding security implies decreasing
> functionality to some extent -- so that to "improve security" and to "make life easy for
> users" seem to be antinomies in all current systems.  Further, it is IMO very close to a true
> antinomy like "slavery" and "freedom".  A secure system must include some amount of
> hassle to a user-- the point is to make it bearable for what it provides, not to deny that
> the hassle exists or, even, that it is less.
>
> [Tom Gindin]   Security and usability are not close to being an antinomy.  They
> are competing goods, and they are subject to a set of trade-offs.  It is true
> that for an optimally designed product one probably can't improve one of them
> without worsening the other, a condition like Pareto optimality in economics.
> However, not every product is on this optimal trade-off frontier, and the
> frontier moves outward over time.  I hope that this WG is doing some things to
> move it outward.

Your vision is IMO sufficiently close to mine for the purposes at hand in this WG. Further,
our visions do not seem to be antinomies themselves ;-) so we can talk about a common
ground, can't we?

Perhaps, the common ground in both visions is to realize the following:

1. More security is not necessarily beneficial to the user.
2. More security will, more often than not, be a hassle for the user; or
2'. Any amount of security will tend to make life harder for users.
3. The purpose of a security protocol is to make security tolerable to users in regard to what it delivers.

What we may still disagree on (but perhaps, just as a matter of degree) is in the fourth item:

4. "Security" and "easier life for users" are simply opposites.

Now, rather than use the "Pareto model" (and its faults), when I want to be more precise I
use in this case the mathematical concept of "conjugate variables" and say that the product
(1/S) .(1/F) > = K describes the relationship between S = "security" and F = "functionality"
in relationship to a constant K>0  valid for a system (of course, in average terms), such that
any increase in S above the limit of S <= (1/F.K) *within that  system* (i.e., for a given K)
must imply a decrease in F, and vice versa .  Moreover, I have reasons to believe that K
is very large in most systems we have today -- so that any amount of S strongly decreases F.

One criteria of "best design" in this formalism is attained when S = F (i.e., when  security and
functionality jointly have their maximum values) -- and which I call a "compact design".
Working with compact designs, one can easily see that decreasing K (with a new system)
directly results in improving *both* security and functionality -- and, is the only  way to do
so above the limit of S <= (1/F.K). The "moving  frontier" you describe is simply given by
decreasing K to K' -- as the system improves to a  new system, but where, likewise, the
"law" (1/S) .(1/ F) > = K' will still hold.

In order to achieve qualitative reductions in K, the design criteria for a new system should be
one (pls. see the relevant URLs) where the concept of Internet security needs to evolve
from "confinement" to "understanding" --  i.e., where security is a mode of understanding and
confinement is but a tool to security.  Indeed, confinement can be useful -- and that is why I
call it a "tool to security" in a design.  "Chinese wall", or "Maginot line" policies are all useful
tools, but if they become the  goal of security then it becomes quite easy to circumvent them
as their historical counterparts showed.  Current fire-walls are also useful, but reliance on
them has actually brought to the front the need for intrusion detection tools -- which is much
more in line with "understanding" than with "confinement".

Because I perceive K to be very large in current systems, I perceive that security and
functionality are close antinomies in current designs -- however, if K would be reduced
then security and functionality would no longer be close antinomies. Let me exemplify.  I
have applied the same mathematical concept here and elsewhere before, for example to
describe the relationship between security (S) and privacy (P) --  which I also consider to
be conjugate  variables,  but such that (1/S) .(1/P) >= Q where Q << K, as I can perceive
in the systems we currently have.  Thus, security is (currently) much closer to be an antinomy
 to functionality than to be an antinomy to privacy, since Q << K.

That is why, today and IMO, "security" and "easier life for users" are simply opposites. Of
course, as a generalization -- but which seems to be very well reflected in actual systems. And,
perhaps this is the main (though largely unspoken by both sides) reason why users say that
"security is not for me yet" (when they reject the hassle) while providers switch into marketing
modes and talk about "non-repudiation" or even "true non-repudiation" (when they try to
overvalue the hassle).  In this regard, my suggestion was that it is better to face the problem,
straight. "Security" and "easier  life for users" are simply opposites, to a large extent. Thus, let's
design methods with this in mind -- and, yes, try to decrease K.

BTW, I found much resonance for these ideas in my talk two weeks ago at the Black Hat
Briefings in LV (slides available), including in talks by other speakers (contact the site).
Bruce Schneier was especially keen on what he described as security being "orthogonal"
to functionality, meaning that just because a security product functions properly does not
mean that it is secure (in my words, the difference between correct and effective); mentioning
also that users do not have the training to follow a "secure" procedure instead of  just choosing
a procedure that works (i.e., users tend to favor functionality over security).  Of course, from
the viewpoint of conjugate variables, security is not orthogonal to functionality and that is why
maximizing one tends to minimize the other -- but both views are just paradoxical terminologies
to describe the same thing, that security and functionality are independent though interrelated
variables.

(BTW, this is nothing out of the ordinary and there are many examples where two variables
are independent but interrelated, as first observed by Fourier in regard to frequency spread
versus time spread for a signal. And, by Heisenberg.)

Cheers,

Ed Gerck