Re: [Nea] privacy: exposing information to owner

[Keith Moore <moore at cs.utk.edu>]

Sean,

thanks for the thoughtful and detailed comments.

on reading your message I realize that trying to lump both the privacy
concerns and the user interface/user naivete concerns into a single
requirement potentially makes that single requirement overbroad and
glosses over important issues that need more detailed examination.

so I'm thinking that it should be separated along something like these
lines:

- the protocol MUST NOT release information about a host to third
parties (other than the owner) absent explicit consent by both the owner
and user to release that information to each specific party
- owners and users MUST have explicit control over the kinds of
information disclosed to third parties
- owners and users MUST be able to control the information which is
allowed to be released on a per-party basis
- owners and users MUST be able to revoke or alter previously-granted
consent
- the model by which owners and users consent to release of information
MUST be easily understood by ordinary users.  (note here that either
too-fine-grained control or too-coarse-grained control can thwart
understanding)

(MUST is probably a bit overused above, but I don't feel like doing much
much wordsmithing at present - I'm mostly trying to identify the areas
of concern.)

I don't think I agree that "Ensuring that the user and owner are
sufficiently aware of the risk in disclosure seems to fall into the
realm of implementation."  implementation clearly plays a role, but so 
does protocol design - at least in the selection of questions that a 
network can ask of a host.  I am increasingly skeptical that this can be 
done, especially if the questions that a network can ask are 
implementation specific.  I'm also skeptical that implementors can be 
trusted with presenting users with a clear picture of the risks they are 
taking - particularly when some implementors will probably have a 
conflict of interest there (say if a particular NEA implementor also 
sells other software and it wants to levy its NEA implementations to 
make sure that such software hasn't been patched, it's licenses are paid 
up, etc.) .


> This sounds very much like the work Kim Cameron and co. are doing with infocards 
> by providing ways for users to choose the profile of identity 
> information they are willing to provide. Can you think of a better
> way to represent this requirement which still allows hosts to connect
> to multiple networks?

something like profiles is probably what is needed in order to make this 
simple enough for users to understand.


> One option down the road is federation. Imagine a company X asset 
> connects to a company X network and gets a normal scan done: nothing 
> which violates your original requirement. Then at the end the asset
> is provided with a certificate signed by company X stating that the 
> machine is running the latest patch, latest AV file, etc, whatever 
> company X is comfortable providing within the certificate. Then when 
> that asset connects to company Y's network it is authorized to
> present the certificate only (which might not even list the specific
> AV vendor, just that it is current). No additional information can be
>  sent regardless of what the user is willing to consent to. Then if X
>  and Y trust each other's assessments they are done.

worth further investigation, I think.

thanks again,

Keith



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