Re: [Nea] privacy: exposing information to owner

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

> IMHO this discussion of whether the protocol will enable invasion of 
> user's privacy is a non-sequiter.

I don't think that word means what you think it means.

> First of all, the NEA protocol is intended to allow the network to 
> transport data between two endpoints on the network with one of these
>  being a host and one of them being a server that will make the 
> decision on what level of access to give to the host. Then the server
>  also has a means to communicate with the network to tell it what 
> access to allow the host and potentially a way to remediate 
> "violations" to policy so that subsequent attempts at access can be 
> allowed. Saying that the user information is exposed to the network 
> is actually

Not sure where you were going here...

> There is nothing in the protocol that states WHAT the data being 
> transmitted between the endpoints will be, that is going to be 
> application specific.

Well, the protocol doesn't exist yet, and we're trying to determine
requirements for that protocol, and a necessary part of determining
requirements is to consider security issues, including privacy issues.
Clearly a consideration of privacy issues involves a discussion of WHAT
the data being transmitted between the endpoints can be.  There is an
inherent conflict between the need to provide some privacy protection
for the user and the (IMHO naive) desire to make this protocol
arbitrarily flexible for the benefit of the network operator.

> As Keith Moore pointed out earlier with his cookie example, just 
> because a protocol is designed for one thing does not mean that it 
> will not be used for other purposes. So what the protocol will do is 
> allow a server to ask a host for ANY conceivable set of data from 
> that host and allow this whole communication to happen in a secure 
> network tunnel.

This does not follow, and if the NEA group were to try to define the
protocol in that way, IMHO it would be extremely unlikely to gain IETF
consensus and subsequent standardization.  That and if I were on IESG
(I'm not) the failure of the NEA group to adequately consider privacy in
its requirements would be a clear indicator that the group should be
shut down rather than be allowed to have its charter extended to
actually develop the protocol under discussion.  Finally the failure to
consider what is best for the Internet as a whole is a violation of IETF
process which should make the group's work vulnerable to being
overturned on appeal.

> With 802.1x as the Layer 2 protocol, the host does not have to have
> layer 3 connectivity to participate in this conversation. To me, this
> is the value of the protocol. What people will say using it and what
> decisions they will make based on what is said are completely beyond
> the scope of the protocol.

Strongly disagree.  The entire purpose of a requirements discussion is 
to narrow the potential solution space and scope of the protocol.

> Saying that we are going to provide a tunnel for endpoints to 
> communicate with each other over a standard protocol says nothing 
> about what the content will be, what decisions will be made based on 
> what data, or anything other than the fact that there is a channel 
> for communications.

That would be true if that were what we were doing.  But we're not doing 
that.

> So if the IETF does not support any protocols that could potentially 
> be used to transmit sensitive user data to others with or without 
> that user's knowledge or assent, then perhaps IP should be 
> elilminated as it too allows for the invasion of user's privacy. 
> HTTP_ check, let's eliminate that too. SSH or SSL? Those are secure 
> but they do allow user's private information to be transmitted across
>  that secure tunnel to another endpoint so guess we'd better
> eliminate those too.

Nope.  See, the entire point of ssh (to give an example) is to allow 
authorized users to be able to run commands under their account on the 
server machine.  ssh users are aware of this purpose, and act 
accordingly.  They don't enable ssh on their machines unless they want 
authorized users to be able to log in to their accounts over the network.

OTOH, the entire point of NEA is to allow networks to determine whether 
a host is safe to connect to the network, NOT to allow networks to 
conduct espionage on hosts that connect to their networks.

> Consider that several successive access attempts, with remediation 
> sessions in between, can occur before a host gets admitted to a 
> network. The first thing checked can be whether the host is trying to
>  comply to the right policy, and the first remediation pass can
> update the policy to the desired one. There is also nothing to say
> that you could not specify several different policies, each with
> different requirements and different levels of network access based
> on compliance to them. So a user could get challenged and select
> which policy he wanted to comply with based on the leve l of access
> he desired, select the policy, get automatically remediated to comply
>  with the selected policy and then be assigned the level of access 
> indicated by the selected policy. It then becomes the user's choice 
> about what he wants to reveal.
>
> In my personal experience, you will end up with users plugging in and
>  being redirected to something that says that they agree with some 
> sort of text that specifies the terms of their network access. They 
> will then accept the EULA and that will eliminate any privacy issues 
> for the network owner. 

But the network owner is not the only party whose interests need to be 
considered.


> I'd like the user experience to look something like this:

[deleted]

I don't see any reason why IETF should endorse a protocol that (a)
allows network providers to conduct arbitrarily surveillance of hosts 
and (b) trusts network providers to be honest about what kinds of 
surveillance users are being subjected to.   That's completely insecure.

> The user could go to an entirely different network and have to comply
>  with a different set of policies. He should have the option at 
> either network to select what he wants to disclose based on what he 
> wants to access.

I do not accept the argument that users will have adequate choice of 
networks to which to connect.  Faith in market forces to solve these 
problems is, in general, misguided.  In my experience that kind of 
argument is usually used as an excuse to justify deliberately creating a 
condition where consumers' interests are harmed.  An IETF working group 
should not be trying to create market conditions that favor network 
providers' interests over those of consumers.  And I don't think you'll 
be able to get community consensus to do that, especially not after 
various privacy groups get wind of what some people here are trying to do.


> BTW, I'd like a little more clarification as to why you think that 
> network owners do not have the right to ask their users anything that
>  locally applicable rules allow. 

I'd like more clarification as to why you think that they do.  But 
that's not what's relevant.  What's relevant is why the IETF should 
endorse a protocol that allows networks to ask arbitrary questions of 
hosts, and in effect, to conduct surveillance of the internal state of 
those hosts - when such a protocol is clearly harmful to users' interests.

Keith


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