Apologies for top-posting, but this is a general reply rather than point-by-point responses…
It feels like a possible goal, then, is a short piece of text which contains sufficient “hooks” to link to other material (which in turn can define specific aspects of the problem in appropriately technical/engineering terms). That might reduce the need for the short piece of text to be magical, while still giving us the means to refer to facets of the privacy problem such as risk analysis, attack models, etc.. As I say, I’d be very happy to work with Dave and others on this, though in the immediate short term I am very limited for bandwidth. In terms of my own expectation: if we don’t achieve the magical two-liner, but we learn something about systematic description of privacy problems in technical/engineering terms, I’ll be happy. If we get a workable, non-engineering-precision two-liner plus some paragraphs in more technical terms, I’ll be radiant. On second thoughts, that prospect may put people off. R PS - now considering trademarking “SPOT” for “Short Piece Of Text” - as in “this is the SPOT definition of x”. > On 5 May 2016, at 16:12, Stephen Farrell <[email protected]> wrote: > > > > 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. > > I'm not even sure the risk analysis method we use for security > is the best way to try address privacy in IETF work. But I did > raise that when 6973 was being done and given that I didn't > have a better method to offer (and still don't) that didn't > make it into the doc:-) > >> >> 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. > > Maybe. I still think that an introductory part of such a document > would be better if we had some definition of what we mean by privacy > when we use the term in IETF documents. (Note: I don't think we need > the one true definition of privacy for the Internet, and I'd agree > with you that we won't get that done.) > > I do like the idea of BCP'ing bits of 6973 where it makes sense to > do so regardless of whether or not we come up with some useful > definition. > > S. > > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
