On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert <tte@xxxxxxxxx> wrote: > Thanks, Tom, inline > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: >> Toerless, >> >> That maybe true, but personal devices, such as smart phones and cars >> that are associated with individuals, are hardly going away anytime >> soon. How addresses are assigned to these devices has a material >> impact on individual privacy. Even right now there are two long >> threads on v6ops right now that are delving precisely into privacy of >> IPv6 addresses that may be relevant. This includes discussion about >> CGNAT and efforts by some governments to illegalize it because the >> privacy it gives is too strong for law enforcement. > > Sure. All i was saying is that we should not dismiss solutions if they > do not help to improve privacy. It reminds me of the congestion control > principles and the fact that a lot of money is made with video in > controlled networks without congestion control. As in: "Sorry, we couldn't > build a great solution for sensor devices in manufacturing plants because > those solutions wouldn't pass the privacy bar". > > I am not even aware if we have good characterizations of solutions > vs. privacy like IMHO we have for congestion control, but of course its > a more complex topic. (IMHO: lot more cases IMHO to distinguish). > > That being said, i would of course love to see that we leverage IDEAs to > also create options that (could) enhance privacy, i just don't think that > we will make a lot of progress if we can not do this work in a WG but > if all the complex issues have to be resolved on pre-wg mailing lists before > even charters are accepted. This is part of whats wrong with the IETF > if i may say so. > > For example, Christian contested that long lived identifiers help to > improve privacy (for device = individual case) and those arguments about > privacy had the IESG turn their opinions. > > IMHO: The long-lived identifiers are meant to be functionally limited. You do > increase the bar of identifying an individual when you do this because the > web applications need to do more work to correlate application layer > information across multiple functional identifiers. > > So, how & where do we even create a common understanding about the qualitative and > quantitative privacy benefits of technology options if not in a WG. Functional > identifiers just being one example. > > Even more fundamentally: If each individual application layer function requires > authentication via e.g.: government, google or facebook ID, and all those > web services are free to correlate their information in the backend, any > network layer privacy work is just like growing organic tobacco. > > Which is why i really would like to know what the state of requirements/BCP etc. > is re. privacy at app layer in the IETF, because without that knowledge, i can > only define the privacy benefits of a network layer enhancement under the > ASSUMPTION of particular application behavior. > I don't think that's true. Privacy enhancements at the network layer are needed to prevent inferences of PII by third party using just network layer information that might be passively intercepted. Knowledge of the application is not needed. In the base case scenario, it should be impossible for a random intermediate node in the Internet to determine who is communicating to whom (identity), where someone is communicating from (location), and what they are saying (content). > My impression of IETF policy is "you have to trust the web services > provider (not to share/correlate/abuse user/client information)" and in the > same breath "you can not trust the network service provider (to behave in the > same way)". Would love to get pointed to documents proving this impression to > be wrong. Especially the option that there can be network providers that > users may want to trust more than arbitrary web services providers should IMHO > be acknowledged. And thats definitely an option i think is worthwhile to build > solutions against. > I doubt there's any IETF RFC or BCP stating whom were required to trust as a MUST. Personally, I don't inherently trust web service providers, network service providers, government, vendors, or really anyone else involved in communications (including myself :-) ). Some trust is needed out of necessity to do anything useful, but we should always be searching for ways to further minimize that. A good example is turning up the TLS on the Internet; this eliminated the need to trust the network with our plaintext. I believe a similar thing will happen with addressing, we'll figure out how to eliminate all PII from addresses so that we don't have to trust the network to not be making inferences that breaks privacy. Tom