Thanks Peter, very useful. I think the underlying “meta”-issue here is emerging…
If we assume that you can start with a “high-level” definition that needs to be applied and interpreted by “lower-level” descriptions and guidance, and that it is theoretically possible to acheve the desired level of precision at those lower levels, then the question then is: can the high-level definition have a degree of vagueness but still be of value? If we can accept (at least as a working assumption) that some level of vagueness in the high-level definition can be consistent with acceptable levels of precision in the descriptive/interpretive text “further down”, then I think that will save us having to agonise over whether the “two-liner” is precise enough… it might be that it can be vague, provided it is inclusive. In other words: you can have a (non-technical) principle, stated in non-technical and possibly vague terms, whose application can be described in precise technical terms. Does this line of reasoning make sense, as a framework for going forward? It seems to me to allow people to contribute at various layers, without making their contribution conditional on perfection at some layer other than the one they’re interested in. R > On 6 May 2016, at 10:56, Peter Schoo <[email protected]> wrote: > > Am 05.05.16 um 17:12 schrieb Stephen Farrell: >> >> >> On 05/05/16 15:53, Alissa Cooper wrote: >>> +1. If people want to consider privacy as a heading under which we >>> group a bunch of different kinds of attacks, that works perfectly >>> well I think. >> >> In the case of privacy, not all the bad things are correctly >> described as attacks IMO. E.g. leaving sensitive data in a >> log file for too long is not in itself an attack, but can be >> risky. Only emitting packets when a user is present similarly. > > Descriptions of privacy (and security taken as example for how to make a > privacy definition) are discussed on different levels. Robin's two-liner > needs to be applied and interpreted. Effect is that it raises > understanding, but takes time and effort to seriously discuss it, which > is good to do. > > On the other hand, it helped to establish, as Christian wrote, > categories for security attacks -- denial of service, information > disclosure, spoofing, elevation of privilege, etc. Agreed attacks > categories form common ground and makes it more useful in standards. > Something similar would be useful for privacy too, as the set of > potential threat is blurred or the understanding of threats and impacts > changes with deeper discussions, more thorough investigations. > > Why are these differences? Sure, the nature of security and privacy are > somewhat different. > >> I'm not even sure the risk analysis method we use for security >> is the best way to try address privacy in IETF work. > > and that's why many apply privacy impact assessments, which have a > different focus when you analyse a system/service/whatsoever, e.g. > concerning time. I argue that security threats typically do not last as > long as privacy threats, they are bound to communication sessions or > periods of subscription - more overseeable. Clever data fusion can > create threats the day after tomorrow. > > Security discussions sometimes comes with properties or services that > shall be provided, e.g. authentication, authorisation, confidentiality, > integrity, availability, or CIA etc. This part of a taxonomy is not > present in the privacy discussion. Like we detail security in > (permutations of) CIA, I miss detailing privacy here. Today privacy > papers often apply Anonymity, Unlinkability, Undetectability, Plausible > deniability and Confidentiality. > > All of the security definition approaches are helpful, two liners, > attacks and properties. Concerning privacy we are still learning about > threats and how to categorize them, to make these categories useful for > standards. Though it might be different with finding a suitable > taxonomy, i.e. relevant to IETF, that help detailing privacy aspects. > > BR > Peter > > -- > Peter Schoo, [email protected] > > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
