|
Hi Ted,
Please see inline.
Cheers, Med De : Ted Hardie [mailto:ted.ietf@xxxxxxxxx]
Hi Mohamed, Some replies in-line. On Fri, Feb 24, 2017 at 12:55 AM, <mohamed.boucadair@xxxxxxxxxx> wrote: Hi Ted,
Please see inline.
Cheers, Med De : Ted Hardie [mailto:ted.ietf@xxxxxxxxx]
HI Mohamad,
I did respond to the particular comments and text proposals, so I assume this is the more general issue. If I understand correctly, you would prefer this document to be structured as
a revision to the threat model document or connected to a larger consideration of the issues. I understand that, and it was considered, but I believe that this format is still the most effective for the narrow issue it addresses. [Med] That was one of my concerns; not the only one. In Particular, I’m trying to understand how this
document will be used in the future to better strengthen forthcoming specifications. Further, the experience I had when advancing some RFCs is that RFC7258 wording can be further enhanced to provide clear guidance. Also, considerations such as the following
are missing from the document: It's difficult to say how something will be used in the future. [Med] An advice that is not implementable makes more troubles, IMHO. My intent (and the understanding of other reviewers) is to highlight that these mechanisms have a privacy-damaging result and that this should be considered. [Med] I do think existing documents already make that job. I do think we need more. In particularly, I'm concerned that some application functions in the network (e.g. recursive resolvers or proxies) do not consider the postive privacy implications of their aggregation and
so do not consider adding this data back as problematic. [Med] I’m also concerned with that, too (see e.g.,
http://www1.icsi.berkeley.edu/~narseo/papers/hotm42-vallinarodriguez.pdf). In the meantime, I’m also concerned with (1) some applications that leak privacy information without the consent of the user and (2) some application servers that may correlate various
information shared by an application client to track users (e.g.,
https://panopticlick.eff.org/). BTW, I see that you are using “application function” which may not have the same meaning as the general “protocol” wording used in draft-hardie-*. Do you consider a DHCP relay as an “application function”?
Highlighting this enables them to see this traffic in a different context. [Med] Isn’t this already assumed by some protocol designers (e.g., RFC6973, SIP)? BTW, there are subtleties when proxies are
in the same trust domain of the client or server. Understood, but even in this case, it is better to make the permission to add the data explicit. [Med] This may be easy to implement for some applications, but this may not be generalized to ** all ** protocols. Putting aside the interaction with a user
to get a consent and how that consent will need to be changed when another user uses the same device to connect to the Internet. Consider a user who does not want an upstream DHPC relay to insert the line-id (https://tools.ietf.org/html/rfc6788)
to the server, and let’s suppose the relay received a signal (by some means, to be yet specified) that for this particular DHCP client, the line-id must not be inserted. For this case, connectivity won’t be provided to that user. This would mean extra calls
to the hotline for that network provider. This is not desirable for both customers and network providers.
Another example is address-sharing (https://tools.ietf.org/html/rfc6269#section-13.1), a misbehaving
user may impact all the users under the same address. I bet such user won’t give his/her permission so that means to demux its packets.
It is also often possible for the end system to gain this data at the cost of other traffic(e.g. the STUN server requests noted in the document). [Med] I’m not sure whether this is ‘often’, but for sure this is possible for some cases. Extra requests may be needed, Indeed. Better, the information may
even be even available locally, for example there is even no need to run STUN/PCP to provide an XFF or Forward-For headers. If this can be done in parallel with other actions, then the latency impact can be minimized. [Med] These are assumptions and implications that are worth to be added to the draft. BTW, this falls into this general discussion in
https://tools.ietf.org/html/rfc6973:
a. Trade-offs. Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, or privacy and other design goals? Describe the trade-offs and the rationale for the design chosen.
This point was discussed extensively in the GEOPRIV work and essentially a single carve-out was made: for emergency services, where falsely asserted location data could be used to SWAT individuals or consume
safety resources. I don't think that falls into this narrow advice, but I would be willing to add something like this to the security considerations: "Note that some emergency service recipients, notably PSAPs (Public Safety Answering Points) may prefer data provided by a network to data provided by end system, because an end system could use false data to attack others or consume resources.
While this has the consequence that the data available to the PSAP is often more coarse than that available to the end system, the risk of false data being provided involved a risk to the lives of those targeted." [Med] Thank you. Providing PSAP as an example is OK, but I’d like the issue to be called out as a generic one while PSAP is provided as an example. What about
the following: "Note that some servers (e.g., emergency service recipients, notably PSAPs (Public Safety Answering Points) [RFC6443]) may prefer data provided by a network to data provided by the end system, because an end system could
use false data to attack others or consume resources. While this has the consequence that the data available to the server is often more coarse than that available to the end system, the risk of false data being provided involved a risk to the lives of those
targeted."
This is true, but it seems to me unrelated to the point of the document. [Med] It is related because blindly trusting an application client (and server) has its own privacy risks. This is even exacerbated given the rich data that
is available to an application client and also because of the visibility on various layers available to an application server.
In general, the point of the document is that the host should be able to omit the data without mid-network devices adding it back. That's the point of protecting the traffic in the first place, after all. I am saying that if the protocols
require the data, then getting it from the end host has better privacy properties than getting from it from mid-network entities. [Med] I’m not sure we can have such general statement because the data may not be available (e.g., DHCP for example) to clients + the data supplied by clients
(when possible) may not be reliable + enforcing policies based on client-supplied data may have implication on other users (e.g., spoofing XFF for example). Obviously, getting some of the information from a client may have implications on QoE…the user needs
to understand the root causes of a degradation of QoE. Of course, these implications may not be new for users who are familiar with disabling _javascript_s and cie.
The Wikimedia case is a very interesting one to raise, because it derives from a set of assumptions about the network that are somewhat flawed and then attempts to patch those flaws in ways that actually damage
the mechanisms of the system they originally built. Wikimedia wants to allow folks to edit without login credentials. This allows for anonymous users to make corrections or additions; this is a goal. The consequence of that goal being achieved is that trolls
or malicious editors can have at anything they want. Rather than institute credentials and ACLs, Wikimedia attempts to substitute blocking by IP for blocking by credential. The property they are looking for in IPs is not really there, though: they are not unique to individuals, especially
over time. [Med] I’m not recommending their solution either, but I’m trying to raise the point that an engineering balance is out there. ACKing that deployment reality
is better than ignoring it.
Thanks again for your engagement on this, regards, Ted
|