On 9/17/2017 5:04 AM, Joel M. Halpern wrote: > > With regard to threats, a lot of the reason I have trouble with > providing good answers is that a service function that stores the > metadata for later analysis is perfectly legitimate. If the operator > contract with the SF provider is that the provider gets the metadata > the service function sees, that the operators chaice. Given that SFs > have to be able to get at whatever metadata they need, the protocol > can not inherently prevent that. People have suggested in > Internet-Drafts mechanisms whereby the SFF trim and restore the > metadata sets. that does not actually rpevent this, it merely adds > the complication that the operator has to configure what is allowed > where. If their contract for a given SF says that it gets all the > metadata, it will get all the metadata. > The one piece we can do is that personally identifying metadata can be > obfuscated, preferably by indirection. We should however recognize > that the indirection will be known to the operator, and if they choose > to reveal it by other means we can not prevent that. I think the security section should list the threats clearly before proposing mitigations. If you don't do that, implementers typically treat the mitigation advice as optional, something that some committee stuck there and that can be ignored. Your point about third party contractors receiving privacy sensitive information is not new. Yes, there can be legitimate business reasons to provide information to third parties. But this normally goes with contractual obligations regarding the handling of the data, such as for what purpose, how it is protected by the third party, for how long it is kept, how and when it shall be deleted, and whether it can be provided further. This means that when such information is transmitted, the transmission should be deliberate rather than inadvertent. As in, if the contract with a third party does not require sending an specific piece of metadata, it should not be sent. -- Christian Huitema