Re: [Nea] privacy: exposing information to owner

["todd glassey" <tglassey at earthlink.net>]

SNIP -

> > Commercial networks lie somewhere in between. They may be willing to
> > grant Internet access if no information is available on the endpoint.
> > Access to corporate resources will probably require some information
> > and the amount of information required will probably depend on the
> > sensitivity of the resources to be accessed (and on local
> > regulations, as Pekka points out).
> >
> > It seems clear to me that this is an areas for local policy.
>
> I don't agree with your assessment.  Just because a network to which a
> host attaches might be run by (say) the military doesn't mean that it's
> reasonable for an Internet standard to facilitate an arbitrary level of
> surveillance or even to give the user a choice about how much
> surveillance is allowed.  I don't see any way to do this that will not
> result, in practice, in users being forced to compromise their privacy
> far beyond that which is reasonable.

Kieth - "Is Reasonable" is an objective term & what you forgot to add is
this:

"Is reasonable by my way of thinking"... something that may not be shared by
all here.

>
> > The endpoint should have a policy about what information it is
> > willing to disclose and to whom.

Funny Kieth I suggested exactly this two plus years ago as part of a policy
negotiation framework inside PKIX and an integrity suite to implement it,
which Stephen Kent and others slammed me to the mat for suggesting again and
again... funny that eh?

> > The network should have a policy
> > about what information it requests, whether it will divulge its
> > policies, and what access it is willing to grant.

yes and that policy needs to be electronically negotiable to end-nodes that
are connecting to its Extranets or Intranet services.

> > The requirement for
> > the NEA standards should be that they describe the security and
> > privacy concerns inherent in this system,

Not inherent in, but rather "Security and Privacy Concerns pertaing to that
systems operation". Remember that the Privacy Concerns are not controlled by
the IETF but rather by global courts and national legislation. So the IETF's
play is not to 'pronounce something private' but rather to build processes
that can be used to implement paperless processes where there is an inherent
or built-in level of privacy specific to those law's requirements.

> > describe how those concerns
> > can be addressed, and require the protocols to include features that
> > enable the endpoint and network to implement whatever policy they
> > want.

> >Then the endpoint and network owners can configure their
> > policies with confidence.

yes. This was the whole point of the Policy Communication Protocol I
proposed to PKIX.

> > One endpoint owner may disable NEA. Another
> > may configure a policy of "Tell nothing but accept advice from my
> > ISP".

NEA could easily be tied to DHCP to prevent the installation of a lease or
in infrastructure to prevent the routing of those 'bad' or 'unquialified'
connections.

> > Others may decide to disclose OS patch info to their corporate
> > servers only. The military owner may configure a policy to disclose a
> > full inventory but ONLY to authorized servers.
>
> Strongly disagree with all of the above.  For the most part, users
> aren't sophisticated enough to determine what the policies on their
> hosts should be.

But the NEA has nothing to do with users. Its a set of tools to demonstrate
the continuing integrity of the systems its layered on. Its not setup (the
NEA) to serve the individual but rather that individual's computer or
workstation as a managed entity in a larger framework.

> This makes them vulnerable to invasion of privacy -
> first as individuals, as naive users succumb to pressure from networks
> to grant more access than is necessary - and then market forces force
> even the more sophisticated users to either accept this privacy erosion
> for themselves or have their access severely limited.  I've seen it
> happen more times than I can count.

So you offer here to protect the world from what? how technical things are?
really?

>
> > For us to decide on a one-size-fits-all policy in this area would be
> > impossible.
>
> perhaps, but that might mean that there is no reasonable solution to the
> NEA approach, and a very different approach is needed.

For what - ?
    a)    Communicating policy requirements and agreeing to participate
under those terms?
    b)    For continuously analysing those systems under management and
reporting on their operational integrity? i.e. are the policies met... ; and
    c)    For raising some alarm if some stateful variable changes outside
of its policy controls?

My take is that there is a solution to the NEA approach,  the problem is in
understanding what each of the NEA flavors or 'agent-services' are to do.
One use is clearly for security, one is for configuration management, one is
for tracking use, one is for 'QoS'... etc etc etc.

so what you really want is the 'anything and everything' daemon and protocol
for it.

Again - I proposed this type of tool sometime ago in my model, but I looked
at implementing the policy control framework on a dat-0centric model that
was based on bottom-up operations. So for me the first step in this is not
in a top-level tool set but in integrating Syslog, NTP, and DNS into the
same shell or framework.

Once the messaging and event tracking system is seamless - then the addition
of the policy controls of NEA make sense to me as an Auditor.

>
> > If we're concerned about naive users, we can require that endpoints
> > ship with NEA disabled and require explicit approval and
> > administrative privileges to enable it or configure policy.
>
> doesn't solve the problem.

Which problem? Is that the problem that the end-users are naive?

>
>
> Keith
>
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www1.ietf.org/mailman/listinfo/nea


_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea