On May 5, 2016, at 7:53 AM, Alissa Cooper <[email protected]> wrote: >> On May 2, 2016, at 2:29 PM, Christian Huitema <[email protected]> wrote: >> >> On Sunday, May 1, 2016 4:12 PM, Dave Crocker wrote: >>> >>> If the term is to be a non-technical and vague reference, then let's stop >> using it >>> as if it were a technical term. Philosophical, academic and social terms >> are >>> fine; the problem is when we use them as if they pertained to technical >>> specifics. >> >> Well, we do use the term "security" liberally, don't we? It is certainly >> just as vague, but it is useful as a section header. It encourages protocol >> designers to be concerned with the broad issue of security attacks. I think >> that we have consensus that protocol designers should also be concerned with >> the broad issue of privacy attacks. > > +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. > > Rather than spending a lot of time to try to find a magical two-sentence > definition that everyone can agree on (which I doubt is feasible), I think > the time would be better spent on refining how we define the set of attacks > and mitigations against them, building on or fixing what’s in RFC 6973, > possibly turning bits of that into a BCP, etc. The two sentences will not be > directly actionable no matter what they say, whereas a comprehensive threat > model and mitigations suite could be.
+1. RFC 3552 doesn't provide a two-sentence definition of "security", but points out that the definition is not simple, but instead a common grouping of properties and threats, which get more detailed definitions in subsequent sections. Similarly, RFC 6973's terminology section does provide technical definitions of terms like unlinkability, fingerprinting, etc. I do tend to agree with the conclusion that as a result we shouldn't be using "privacy" as a technical term on its own. Sentences in specs of the form "Feature X undermines privacy" or "Feature Y provides privacy to the end user" are either inappropriate, or more likely, incomplete. Instead: "Feature Y supports privacy by providing unlinkability of traffic between requests". It might still be useful to refine a short definition that can be cited to speed up conversations on privacy at IETF or help in scoping work; NIST, for example, has been trying to come up with privacy engineering objectives analogous to the C-I-A triad for security. Cheers, Nick
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
