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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
