Subject: Re: [Nea] IETF67 NEA WG Meeting summary

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 17:04:38 -0500

> I often avoid situations where I may be requested to provide
> information I'm not willing to provide.  There is nothing new in
> that.  Providing I have the choice to provide the information or not
> it isn't a problem for me. Consumers have enough market force to
> ensure organisations will not request more than what may be
> reasonable.

sometimes they do, often they don't.  it depends on the market, and also 
on consumer awareness.  a lot of automobile purchasers aren't aware, for 
instance, that the new car that they are buying records information 
about their driving habits that can be used against them.

> It is considered reasonable to put people through security before
> they can fly out of the country or even often, within a country.  The
> amount of security the public is willing to put up with is still
> being worked out, personally I find it intrusive but am willing to go
> along as it is for the public good.

and a lot of people (including myself) are not nearly so willing to fly 
commercially as they used to be.

> There are already mechanisms that will do such searches and they are
> being used, at a higher level than NEA.  

sure, but we're talking about what IETF should standardize, not about 
what already exists.  the existence of bad things does not compel IETF 
to bless them.

Keith

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 14 Nov 2006 20:27:05 -0500

Can you please move this entire thread elsewhere? It is not
sunstantive to the discussion of setting ID requirements. If you are
unwilling to do that, then how about adding something substantive.

For example, Keith, you have referenced time and time again vague
risks to privacy.  Can you spell out in clear and actionable terms
what those risks are? A bulleted list with a short description would
be useful.

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 01:00:42 -0500

> unwilling to do that, then how about adding something substantive.

no, I'm not willing to move this thread elsewhere, because security and 
privacy issues are at the crux of the problem that NEA must solve if it 
is to meet rfc 2026 criteria and gain community consensus.

> what those risks are? A bulleted list with a short description would

it's too simple a concept for a bulleted list.

how difficult is it to understand that people don't want the contents of 
their hard drives to be subjected to arbitrary searches as a 
precondition to being able to access networks?

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 15 Nov 2006 08:45:25 -0500

> precondition to being able to access networks?

Please, if the list is so simple, then perhaps you can spare a minute
to list them out? Or are you unwilling to explicitly state your
opinion?

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 09:32:12 -0500

-------- Original Message --------

> to list them out? 

I don't understand - what do you want me to list?  examples of potential 
contents of someone's hard drive that a user might not want to be disclosed?

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 15 Nov 2006 09:52:15 -0500

> contents of someone's hard drive that a user might not want to be disclosed?

I am asking you to list in clear and concise terms the "privacy
issues" you have. Is exposing the contents of a hard drive the only
issue you have, or are there more? If there are more, then state
please list them.

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 10:14:29 -0500

> issue you have, or are there more? 

oh, okay, I see what you mean now.

exposing the contents of the hard drive isn't the only issue I'd have. 
exposing what is running on the cpu would be another issue, exposing 
what is talking to what network local or remote ports or addresses would 
be another, as would be exposing the existence of other network 
interfaces and what they're connected to.

it's a bit hard to tell where the issues end, as the NEA charter is 
fairly ambiguous as to what constitutes "posture".

Keith

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 15 Nov 2006 10:59:16 -0800

The risk is indeed easy to understand.  

It needs to have a mitigation mechanism and we need a mechanism that
allows the owner of a host to explicitly choose to undertake the risk or
not.

By way of mitigation measure we can articulate a requirement that the
protocol MUST be capable of employing some authentication measure to
determine who is asking for the information.

We should also have a requirement that the protocol MUST be run only
when authorized.  Meaning some mechanism in the host needs to explicitly
allow the protocol to communicate information.  There MAY, additionally,
be fine grained controls that authorize specific sub-sets of the
information based on identity/anonymity of the requestor.  The
authorization MAY allow that all requestors be provided the information
requested.  This is perfectly appropriate for situations that have other
mitigating measures.  For example a corporate server / desktop that is
never expected to leave the building and / or be on any other network.
As long as this is an explicit risk management choice made by the owner
of the asset it should be fine.  

Khaja

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 15:51:55 -0500

-------- Original Message --------

> of the asset it should be fine.  

I disagree, for reasons given earlier.

It's not acceptable to allow an arbitrary network to ask arbitrary 
questions of a host, even if the user gets to control which questions 
are answered, because this provides a sufficient mechanism to coerce the 
user into giving up his privacy - either because the user doesn't 
understand the implications of his decisions (likely) or because the 
user doesn't, for practical purposes, have a choice (also likely).

Keith