Hi Brian, On 09/15/2013 08:42 PM, Brian Trammell wrote: > hi Stephen, Benoit, all, > > The survey of anonymization techniques in 6235 was intended primarily > to be a complete accounting of methods one _could_ use to anonymize > fields (Information Elements) in a record, as opposed to a survey of > methods we knew to be implemented. Here the idea was to allow a > complete specification of a metadata format for specifying how > records were anonymized, as input to future analysis tasks to be done > on the data (since the anonymization method affects the set of > analyses for which the data can be used). > > So we were really trying to solve a different problem: applying > anonymization (to mask irrelevant and potentially privacy-sensitive > information) while still maintaining the usefulness of the data for > specific analytical tasks. Here we'd like to get rid of absolutely > _everything_ that might be useful for analysis, just keeping around > the minimum necessary for the operation and management of the > protocol. > > Which gets me back to thinking it would be very useful to have a > survey of the information radiated by protocols in common usage, then > a systematic exercise to make sure each of those bits of information > which may be identifiable serves a purpose that couldn't be done in > an anonymous or pseudonymous way.
A fine research proposal. (Really, I'd try get dosh for that:-) But in an IETF context, maybe that'd be a thing that the lmap wg [1] could look at? Anyone on this list active there? The lmap charter says: "The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined." (However, if I recall correctly I got that sentence shoe-horned into their charter, so its not clear to me if the active participants are actually keen on it or if it'll turn out to be RFC6919 fodder;-) S. [1] http://datatracker.ietf.org/wg/lmap/charter/ > > Cheers, > > Brian > > On Sep 15, 2013, at 7:44 PM, Stephen Farrell > <[email protected]> wrote: > >> >> Hi Benoit, >> >> On 09/14/2013 12:02 PM, Benoit Claise wrote: >>> On 13/09/2013 14:37, Stephen Farrell wrote: >>>> >>>> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>>>> Hi, >>>>> >>>>> I would very much like to see servers having a minimal >>>>> logging policy by default, especially and at least when it >>>>> comes to IP addresses. I wonder if RFC 6302 is the right >>>>> document to look at or extend for this. >>>> Or obsolete it. >>>> >>>>> It is easy to flip a switch to enable IP logging. The default >>>>> should be no IP logs, which is true for most XMPP servers, >>>>> for example, but not for web or mail servers. >>>> The wonderfully ironically named PRISM [1] project was an EU >>>> funded project that did some work on obfuscating IP addresses >>>> in logs. >>> rfc6235 >> >> Yep, sections 4 & 5 of that are generic and not really ipfix >> specific. >> >> Do you know of implementations of that for ipfix? Or libraries that >> do the various functions? >> >> I wonder if separating those sections out into a separate RFC would >> result in more people writing code that supports those kinds of >> transformations. Not sure to be honest. >> >> But that is a useful reference, regardless, Thanks, S. >> >>> >>> Regards, Benoit >>>> >>>> I'd love to see an RFC that described such techniques and >>>> recommended when to use what, so we could point people at >>>> that. >>>> >>>> Any takers for a -00 to get that going? >>>> >>>> S. >>>> >>>> [1] http://www.fp7-prism.eu/ >>>> >>>>> On a side node, can we do anything to get rid of sender IP >>>>> addresses in (the first) Received headers of mail? >>>>> >>>>> -- Moritz _______________________________________________ >>>>> perpass mailing list [email protected] >>>>> https://www.ietf.org/mailman/listinfo/perpass >>>>> >>>> _______________________________________________ perpass mailing >>>> list [email protected] >>>> https://www.ietf.org/mailman/listinfo/perpass . >>>> >>> >>> >> _______________________________________________ perpass mailing >> list [email protected] >> https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ perpass mailing list > [email protected] https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
