From turners@ieca.com Wed Jan 5 06:02:10 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3483A6C18 for ; Wed, 5 Jan 2011 06:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLfHIy+FOg1x for ; Wed, 5 Jan 2011 06:02:09 -0800 (PST) Received: from nm6-vm0.bullet.mail.ac4.yahoo.com (nm6-vm0.bullet.mail.ac4.yahoo.com [98.139.52.70]) by core3.amsl.com (Postfix) with SMTP id 5D97E3A6C05 for ; Wed, 5 Jan 2011 06:02:06 -0800 (PST) Received: from [98.139.52.192] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 14:04:10 -0000 Received: from [98.139.52.173] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 14:04:10 -0000 Received: from [127.0.0.1] by omp1056.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 14:04:10 -0000 X-Yahoo-Newman-Id: 814761.67022.bm@omp1056.mail.ac4.yahoo.com Received: (qmail 30317 invoked from network); 5 Jan 2011 14:04:10 -0000 Received: from thunderfish.local (turners@96.231.119.109 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 05 Jan 2011 06:04:10 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 4WVdEFEVM1msspK0YZf7GJ.LQ2Wshf4Ao91MVQp0GjZno8P jJaXg_TF95zBmHOm_pfRXCao9OoyS_cQRPfTJhKf3kqCglpf8GtvVtOVocLe 7EQ.4N3wmqbfoa6G7fzLqhLiv0.hAzmOV8kYGa1bs7UZBfiwmacWFScRafBM xUo3FY_jtb0iY4G1Bb.uxthfQhcZmEMt0bRDVJrXDcrJm1lazE8Fv1L8FI2U VSb2AJQzmnakU.j5w4uvXfrdTXm8sbCigkrXqckebRP50vx4OpHZrckyWwTI 8r6w21E1JBiaQCDUrRW8qgNyWItnS3kh960c6hiVatd5rfH244EbVaF_AeEX igkwdHEWFus8ASTGV8nkK36VgUhRClPhnLaLuwqo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D247A58.3070605@ieca.com> Date: Wed, 05 Jan 2011 09:04:08 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [privacydir] getting things started X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:02:10 -0000 Everyone, Thanks for agreeing to be in this directorate. The purpose is twofold: 1. Provide a place to discuss the Privacy Considerations for Internet Protocols draft (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/) 2. Test out the recommendations in that draft by reviewing selected drafts. Most that I talked to about this directorate liked the idea that it would be modeled on the security directorate. To do that we'll need a secretary to review the upcoming IESG telechat agenda (https://datatracker.ietf.org/iesg/agenda/documents/), select drafts to review, and assign drafts to reviewers. What that means is that we'll actually need people to review drafts and send their comments to the directorate. The workload will, I think, at most be one draft a month per person. Now there are only 15 or so, but we've had 30 requests to join the directorate. So, the workload could actually drop. I've gotten at least one recommendation for a secretary and Tim and I will see if they'd be game. I suspect the assignment process will happen by generating the list of directorate reviewers and then just working through the list. Tim and I had picked out two drafts that seemed bang on appropriate for the directorate to review: https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ and https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ Tim and I both have some initial comments on the httpstate-cookie draft. You can see them by clicking on the IESG evaluation tab in he datatracker. If you think we've missed something please send email to this list. Nick Mathewson provided Tim and I with some comments on the ipfix-anon draft which I will forward shortly to the mailing list. Cheers, spt From turners@ieca.com Wed Jan 5 06:03:23 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD983A6C05 for ; Wed, 5 Jan 2011 06:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2xg6UqKLzl1 for ; Wed, 5 Jan 2011 06:03:21 -0800 (PST) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by core3.amsl.com (Postfix) with SMTP id B33743A6C18 for ; Wed, 5 Jan 2011 06:03:21 -0800 (PST) Received: from [98.139.91.68] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 14:05:26 -0000 Received: from [98.139.91.41] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 14:05:25 -0000 Received: from [127.0.0.1] by omp1041.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 14:05:25 -0000 X-Yahoo-Newman-Id: 929015.8143.bm@omp1041.mail.sp2.yahoo.com Received: (qmail 93114 invoked from network); 5 Jan 2011 14:05:25 -0000 Received: from thunderfish.local (turners@96.231.119.109 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 05 Jan 2011 06:05:24 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: BHipV9IVM1lYHemYjjX2cEkBaz3S4lyZyYSgaRUZTykNMNS 7EohpcU9nKpMl9LmlhEKV.oRYqOS4PVk5skJBUyC71PXd6eGGnW18UWAJdxq ZdLrPT_bhXa2dwxhIK8yMO93VO4sNjHBZL8NEQCUkP_KLn39YsjSk7xwz94l JNEYk.jJb9hhjaD2dIsaX4ylvtNXuKJKn43qHqtNX7I2yf9KY1RjjxEkUhuV R6AMLgXiAlEG5vgyIqCz1KBDNf2vX9zkh8KIM5rpCRIq7nrYGabrK3vqt9nM ICjIgFDKhu.EHQRWtFddtpbeEhwIUhaVN5GNJ2yfJPcI1cAJSPuSbDlvJL5S cgrK_oNv5auE_oB2D.BD1PchFkEmIJRGCIQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D247AA3.1060500@ieca.com> Date: Wed, 05 Jan 2011 09:05:23 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [privacydir] Fwd: Review of draft-ietf-ipfix-anon X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:03:24 -0000 Here's Nick's review. spt -------- Original Message -------- Subject: Review of draft-ietf-ipfix-anon Date: Thu, 30 Dec 2010 14:02:55 -0500 From: Nick Mathewson To: Sean Turner My expertise here is on anonymity and privacy enhancing technologies in general, and not in IPFIX, so please take my observations with the appropriate amount of skepticism. Also, I've not had much prior experience reviewing IETF drafts, so please forgive any suggestions I make that are out-of-scope for this document. A couple of minor notes on terminology: - The discussion and definition of 'anonymization' here may be the one more usually used when referring to data flows, but there are larger fields at work here that it might be a good idea to harmonize with. The idea of deleting fields or aggregating records in a data set is more closely associated with the topic of inference control (see also work on "k-anonymity"). For these, the Inference Control subsection of Ross Anderson's "Security Engineering" is a reasonably good introduction. The idea of anonymity in general seems more closely tied to notions of untraceability and unlinkability; for those see Pfitzmann and Hansen "A terminology for talking about privacy by data minimization". It's no disaster (and certainly not unprecedented!) to have the meaning of "anonymize" be context-dependent, but it _is_ important to say what property you actually mean to achieve thereby. See also the notes below on section 3. - The authors should decide whether they're going to use American or British spellings. The draft uses the American spellings for categorize, organize, minimize, behavior, and so on, but unaccountably uses the British "-ise" in anonymise and pseudonymise. In the research literature, and in the other relevant RFCs, "anonymize" seems to be more popular, but either spelling type is fine so long as it's consistent. Sec 1: It might be wise to repeat here (or even in the abstract) the note from the Security Considerations section that this draft is only meant to explain how to interchange anonymized data, not to provide any recommendations as to which anonymization techniques to use, or even any guarantee that any particular technique achieves any particular purpose. Otherwise, it is easy to misread some parts of section 4 as promising that particular techniques will prevent particular attacks, which is not in fact the case for reasonable threat models. It would also be useful to note that this draft _only_ considers the kind of inference control you can achieve through transformation of individual flow records. Aggregation-based anonymization is not considered --and not even included in this draft's definition of anonymization!-- even though it provides more robust privacy results. Sec 3: notes on goals So it seems that the goal of anonymization, as stated here, is to prevent IP flow data from being traced to the networks, hosts, or users that participated it. But this is only one possible goal of these techniques. Other uses of the anonymization techniques in this draft include: - One-way untraceability. Under some circumstances, it is fine to identify the originator/recipient of a given flow, but not both. For example, it might be fine to identify users so long as the services they use can't be inferred, and it might be fine to identify servers so long as you can't tell who their users are. - Resistance to partner profiling. Even if no particular flow can be linked to a particular entity, it might be undesirable for the set of flows as a whole to be useful for statistically inferring certain properties of networks, hosts, or users. For example, even if an attacker can trace no specific flow to users Alice and Bob with confidence greater than 0.01%, if they could nevertheless infer that Alice and Bob communicate regularly with P=99%, Alice and Bob would reasonably consider their privacy to have been compromised. For a more rigorous of an attack that achieves profiling without tracing specific interactions, see Danezis's Statistical Disclosure attack. - Non-observability. It might be undesirable for a flow or set of flows to confirm that a particular entity was in fact present or absent at a given time. Some related desirable properties include: - Non-linkability. It might be undesirable for two flows generated by the same entity to be linked to one another. Linkability between flows is a strong amplifier for traceability attacks: if through mischance, misdesign, or external knowledge, an adversary manages to trace a single flow to one of its entities, then linkability between flows means that _all_ of that entity's flows are now traced. Website Fingerprinting ("Fingerprinting Websites Using Traffic Analysis", Andrew Hintz, 2002) is an example of a more subtle attack enabled by flow linkability. - Ccorrelation resistance. It might be undesirable for anonymized flows processed by different IPFIX installations to be correlated to one another. For example, suppose that the same flow is anonymized one way as it travels through network A, and another way as it travels through network B. It might be the case that neither anonymized flow on its own has enough information to identify a user, but that both flows, taken together, can identify the user. If this is so, and an attacker might see both anonymized flows, then it becomes critical to ensure that the adversary cannot easily learn that the two anonymized flows refer to the same flow. I'm not proposing that every IPFIX user should want all of these properties under all circumstances, but without them, the untraceability properties become more fragile and much harder to achieve. It seems that elsewhere in the document, requirements _like_ these are considered, though they're usually not explicit. Instead, the document only says that certain properties that are not themselves identifiers "can be used to identify hosts and users" without much considering how in some cases. Sec 3: notes on threat modeling (Perhaps this applies better to the security consideration section. Either way, without a discussion of known attacks against entities' privacy, it's hard to have a meaningful discussion of how privacy can be achieved.) Privacy, like security, requires us to consider threat models. In other words, we need to state our privacy requirements in terms of an attacker's resources, and what count as a successful attack. The part of this draft that worries me most is that, when discussing "untraceability", it does so with no actual explicit attacker in mind. Because there isn't an explicit threat model or collection of threat models, it's not really possible to say whether some of the attacks and caveats below are really "valid" attacks against their anonymization methods, because "without an treat model, there are no vulnerabilities--only surprising features." For example, some places in the draft discuss "traffic injection" attacks, implying an active attacker. But other places in the draft claim that anonymization techniques are effective when they _do not_ resist an active attacker. Sec 4: Throughout this section, it seems potentially misleading to say what various anonymization techniques are "intended to defeat", and so on. A naive reader could take this to mean that a technique _actually does_ defeat one of these attacks, or that it _actually will_ provide a given degree of privacy, which I think is not what the authors are trying to say. On the other hand, if this draft _is_ trying to say which techniques achieve what, then it needs to be much, much more specific about the threat models and circumstances for which its statements are true. sec 4.1.2: "Reverse truncation is effective for making networks unidentifiable" -- this is not so if the adversary can be assumed to know a little bit about the network. For example, assume we have removed all but the last 8 bits of the IPv4 address, but we have left port numbers unchanged. An attacker reading the anonymized flow data can still learn which hosts are running which services, and match this service map (fuzzily) to known service maps on networks of interest. sec 4.1.3: Surely we should say something about the security requirements of the permutation function. There is all the difference in the world between, say, a block cipher and an xor with a known constant, but this section doesn't actually make that distinction. Below, in section 5.4, the draft says that the permutation and its parameters SHOULD not be exported, but that's not quite the same as saying that the permutation SHOULD be hard to invert without knowing its parameters. Similarly, the recommendation to use a hash function can fail badly if the hash function is known to the attacker: it is trivial for the attacker to brute force all IPv4 addresses to deanonymize subjects if a known hash is used. HMAC with a secret key would be more appropriate. 4.2: See notes from 4.1 above. Brute-forcing a 48-bit MAC addresses is harder than brute-forcing a 32-bit IPv4 address, but not out of reach even for a hobbyist. 4.3: There is existing research on the extent to which the beginning and ending times of related flows can be used to link an anonymized view of a flow to a non-anonymized view of the flow. See Murdoch and Zelinski's "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries". [ http://petworkshop.org/2007/papers/PET2007_preproc_Sampled_traffic.pdf ] 4.3.2: An active attacker who can create recognizable flows can turn an enumerated timestamp dataset into a precision-degraded dataset by periodically injecting a recognizable flow. 4.3.3: Adding a uniform random shifts is remarkably fragile: if the adversary can identify the correct time for even one flow, he can learn the times for all other flows. Worse, if datasets are generated continuously, with each one starting right after the previous one finishes, then the attacker who knows the shift for one dataset can place bounds about the shifts for all close-in-time datasets by induction. 4.3 and 4.4, in general: There is a pretty extensive literature about the extent to which perturbing timing and volume information prevents correlation, linkability, and website fingerprinting. Check out the traffic analysis section of freehaven.net/anonbib, and also check out the literature on "stepping stone detection". The results are unintuitive to many people; in general, to resist correlation and linkability attacks, you need to use perturbations of higher-variance or bins of larger size than many implementors would expect. 5.3, 5.4: **This point is critical**: Statements to the effect of "Information about [the particular anonymization technique used] SHOULD NOT be exported" are a total violation of Kerckhoffs' principle: the security of a system should depend only on the secrecy of key-like parameters, not on the secrecy of its algorithms. In practice, after all, any competent attacker will know which permutation functions and binning functions are implemented by the popular IPFIX vendors. Any aspect of permutation/binning which the attacker must not learn needs be keyed with a secret key that can be changed locally. Section 9: A risk that it could be worthwhile to mention: Frequently, anonymized data will be treated by administrators as "not privacy-sensitive" when in fact it should only be treated as "less privacy-sensitive." (For examples in other fields, see the results concerning user reidentification from AOL's search terms, or Netflix film queues.) The anonymization techniques described here do indeed make entities associated with flows harder to trace ... but there is a risk that when they are applied, administrators will treat flow data as "completely safe" when in fact it has only become "less harmful if misused". From turners@ieca.com Wed Jan 5 10:22:51 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0172B3A6C17 for ; Wed, 5 Jan 2011 10:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8KNDHTEDizn for ; Wed, 5 Jan 2011 10:22:47 -0800 (PST) Received: from nm5-vm0.bullet.mail.ac4.yahoo.com (nm5-vm0.bullet.mail.ac4.yahoo.com [98.139.52.68]) by core3.amsl.com (Postfix) with SMTP id C31863A6BE9 for ; Wed, 5 Jan 2011 10:22:47 -0800 (PST) Received: from [98.139.52.188] by nm5.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 18:24:51 -0000 Received: from [98.139.52.170] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 18:24:51 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 18:24:51 -0000 X-Yahoo-Newman-Id: 858161.48800.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 91333 invoked from network); 5 Jan 2011 18:24:51 -0000 Received: from thunderfish.local (turners@96.231.119.109 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 05 Jan 2011 10:24:51 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: IMvgXYMVM1lBRbsPO6SeBM0ka23E.q60MXkBPgQVQiAM1Fo ZnxG7rW7QSXLAW8g5X_GSRwOTFxVl8D9oU59Nmo9Lp_wLxOT3CqtJ7f_ijOO NyAdLF6XhLTlbeN8UQc8abNuhiELdrdJiqSYja7NU0J6jnJ4c33HAPpSTwzm yKiqq4REZaDAHngbGEUhn7WFUIeTYzhTJfja4C1GcUwwscmlYTTzBTH.zlrt nMPMmk2bHXW2PPrW147kF9ZP7bW7QH4cobnqsaBzOjou42NXbYkaGNBapmVg kgS.NiQoKEl9XoNPMuHU9t5yVxki4CSzS_nmF.E595W3zEsrsu7wE4it14jp DSEMyA4.vkRHNb0owb88Y3pqBBIVvqzZDynvohQ4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D24B772.3060703@ieca.com> Date: Wed, 05 Jan 2011 13:24:50 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: multipart/mixed; boundary="------------020801070607020703010306" Subject: [privacydir] Fwd: I-D Action:draft-koenig-privicons-01.txt X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:22:51 -0000 This is a multi-part message in MIME format. --------------020801070607020703010306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I see that some of you were involved in this. In case you weren't aware of the draft, there's a link below to it. spt -------- Original Message -------- Subject: I-D Action:draft-koenig-privicons-01.txt Date: Wed, 05 Jan 2011 09:00:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Privacy Preferences for E-Mail Messages Author(s) : U. Koenig, J. Schallaboeck Filename : draft-koenig-privicons-01.txt Pages : 17 Date : 2011-01-05 This document proposes a syntax and semantics as an extension of the Internet Message Format (e-mail message) allowing a Sending User of an e-mail message to express his or her preference for how the message content is to be handled by the Receiving Users. For this purpose, semantics of sets of different character combinations ("Privicons") are described. These can syntactically be integrated either in the first-line of the body, in the subject line and/or in a dedicated header of any e-mail message. The Privicosns icon set consists of six different icons. They'll be machine readable. The Privicons concept is partly borrowing its approach from the concept of emoticons. For example, to express that the content may be forwarded and even be published. The Sending User could use the Privicon "[>]", which may be followed by an additional explanations, such as "please share". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koenig-privicons-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020801070607020703010306 Content-Type: Message/External-body; name="draft-koenig-privicons-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-koenig-privicons-01.txt" Content-Type: text/plain Content-ID: <2011-01-05084721.I-D@ietf.org> --------------020801070607020703010306 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------020801070607020703010306-- From dkm@ischool.berkeley.edu Thu Jan 6 10:56:44 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07493A6CC6 for ; Thu, 6 Jan 2011 10:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4RfivkQhhZT for ; Thu, 6 Jan 2011 10:56:44 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by core3.amsl.com (Postfix) with ESMTP id 47C053A6F40 for ; Thu, 6 Jan 2011 10:56:43 -0800 (PST) Received: from azure.ischool.berkeley.edu ([128.32.226.26]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (auth plain:dkm@ischool.berkeley.edu) (envelope-from ) id 1Pav2v-000423-9p; Thu, 06 Jan 2011 10:58:50 -0800 Message-ID: <4D2610E8.5060105@ischool.berkeley.edu> Date: Thu, 06 Jan 2011 10:58:48 -0800 From: Deirdre Mulligan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sean Turner References: <4D247A58.3070605@ieca.com> In-Reply-To: <4D247A58.3070605@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] getting things started X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:56:45 -0000 Hi Sean et al Can you tell me what the timeline is on the two below? I am happy to take on some of the evaluation work under 2 and will plan to work it into a lab class I am running this semester looking at policy implications of technical design. On topic 1, I would suggest that we think about other models--both decisional documents, expert committees, etc. -- in addition to the morris draft for iding and working through privacy issues in drafts. thanks and happy new year. cheers deirdre On 1/5/11 6:04 AM, Sean Turner wrote: > Everyone, > > Thanks for agreeing to be in this directorate. The purpose is twofold: > > 1. Provide a place to discuss the Privacy Considerations for Internet > Protocols draft > (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/) > > 2. Test out the recommendations in that draft by reviewing selected drafts. > > Most that I talked to about this directorate liked the idea that it > would be modeled on the security directorate. To do that we'll need a > secretary to review the upcoming IESG telechat agenda > (https://datatracker.ietf.org/iesg/agenda/documents/), select drafts to > review, and assign drafts to reviewers. What that means is that we'll > actually need people to review drafts and send their comments to the > directorate. The workload will, I think, at most be one draft a month > per person. Now there are only 15 or so, but we've had 30 requests to > join the directorate. So, the workload could actually drop. > > I've gotten at least one recommendation for a secretary and Tim and I > will see if they'd be game. I suspect the assignment process will happen > by generating the list of directorate reviewers and then just working > through the list. > > Tim and I had picked out two drafts that seemed bang on appropriate for > the directorate to review: > > https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ > > and > > https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ > > Tim and I both have some initial comments on the httpstate-cookie draft. > You can see them by clicking on the IESG evaluation tab in he > datatracker. If you think we've missed something please send email to > this list. > > Nick Mathewson provided Tim and I with some comments on the ipfix-anon > draft which I will forward shortly to the mailing list. > > Cheers, > > spt > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir -- Deirdre K. Mulligan Assistant Professor School of Information UC Berkeley dkm@ischool.berkeley.edu 510.642.0499 From turners@ieca.com Fri Jan 7 13:13:22 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F7E3A6946 for ; Fri, 7 Jan 2011 13:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysyNFCoB7T5f for ; Fri, 7 Jan 2011 13:13:21 -0800 (PST) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by core3.amsl.com (Postfix) with SMTP id 9527B3A68C5 for ; Fri, 7 Jan 2011 13:13:20 -0800 (PST) Received: from [98.139.52.188] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:15:24 -0000 Received: from [98.139.52.176] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:15:24 -0000 Received: from [127.0.0.1] by omp1059.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:15:24 -0000 X-Yahoo-Newman-Id: 249788.93348.bm@omp1059.mail.ac4.yahoo.com Received: (qmail 16687 invoked from network); 7 Jan 2011 21:15:23 -0000 Received: from thunderfish.local (turners@71.191.14.103 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 07 Jan 2011 13:15:22 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: MgeCNWoVM1lGYNpVTiQKa9bl8LAVQ4KccxbqYG8slOfWK4h Wkl8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D278269.4010509@ieca.com> Date: Fri, 07 Jan 2011 16:15:21 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Deirdre Mulligan References: <4D247A58.3070605@ieca.com> <4D2610E8.5060105@ischool.berkeley.edu> In-Reply-To: <4D2610E8.5060105@ischool.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] getting things started X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:13:22 -0000 The two drafts below were on yesterday's IESG telechat. For the ipfix-anon draft, I submitted Nick's comments pretty much in their entirety. I haven't heard from the authors. There's essentially still time if somebody uncovers something horrible. The time frame for anything on that draft is at best two weeks. For the cookie draft, time is short - actually technically it's over because IETF LC ended a while ago. The author is very responsive too. If you've got any comments I need them as soon as possible and unfortunately there's no guarantee the author will incorporate them. This just goes to show we need a secretary to ride herd on us. spt On 1/6/11 1:58 PM, Deirdre Mulligan wrote: > Hi Sean et al > Can you tell me what the timeline is on the two below? > I am happy to take on some of the evaluation work under 2 and will plan > to work it into a lab class I am running this semester looking at policy > implications of technical design. > > On topic 1, I would suggest that we think about other models--both > decisional documents, expert committees, etc. -- in addition to the > morris draft for iding and working through privacy issues in drafts. > > thanks and happy new year. > cheers > deirdre > > On 1/5/11 6:04 AM, Sean Turner wrote: >> Everyone, >> >> Thanks for agreeing to be in this directorate. The purpose is twofold: >> >> 1. Provide a place to discuss the Privacy Considerations for Internet >> Protocols draft >> (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/) >> >> 2. Test out the recommendations in that draft by reviewing selected >> drafts. >> >> Most that I talked to about this directorate liked the idea that it >> would be modeled on the security directorate. To do that we'll need a >> secretary to review the upcoming IESG telechat agenda >> (https://datatracker.ietf.org/iesg/agenda/documents/), select drafts to >> review, and assign drafts to reviewers. What that means is that we'll >> actually need people to review drafts and send their comments to the >> directorate. The workload will, I think, at most be one draft a month >> per person. Now there are only 15 or so, but we've had 30 requests to >> join the directorate. So, the workload could actually drop. >> >> I've gotten at least one recommendation for a secretary and Tim and I >> will see if they'd be game. I suspect the assignment process will happen >> by generating the list of directorate reviewers and then just working >> through the list. >> >> Tim and I had picked out two drafts that seemed bang on appropriate for >> the directorate to review: >> >> https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >> >> and >> >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >> >> Tim and I both have some initial comments on the httpstate-cookie draft. >> You can see them by clicking on the IESG evaluation tab in he >> datatracker. If you think we've missed something please send email to >> this list. >> >> Nick Mathewson provided Tim and I with some comments on the ipfix-anon >> draft which I will forward shortly to the mailing list. >> >> Cheers, >> >> spt >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir > From william.polk@nist.gov Tue Jan 11 07:06:34 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D2A28C193 for ; Tue, 11 Jan 2011 07:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANjUBoNYm0bV for ; Tue, 11 Jan 2011 07:06:26 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 00F6D28C2CB for ; Tue, 11 Jan 2011 07:06:25 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p0BF8fH2001452; Tue, 11 Jan 2011 10:08:41 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 11 Jan 2011 10:08:28 -0500 From: "Polk, William T." To: Deirdre Mulligan , Sean Turner , "npdoty@gmail.com" Date: Tue, 11 Jan 2011 10:08:26 -0500 Thread-Topic: [privacydir] getting things started Thread-Index: Acut078U6caiJoxiSuWPf6FC4zJSGQDzaZfy Message-ID: In-Reply-To: <4D2610E8.5060105@ischool.berkeley.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C951DC9A1D404wpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Cc: "privacydir@ietf.org" Subject: Re: [privacydir] getting things started X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:06:34 -0000 --_000_C951DC9A1D404wpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Deirdre, There is no fixed timeline on any of this - this is more of an experiment. = We can't take more concrete steps, like a BCP that adds privacy considerat= ions to the required scope of Security Considerations, until we build rough= consensus that the experiment worked. There are certainly other holes to = fill, but Sean and I see this as the low hanging fruit in the frighteningly= complex privacy space. It is probably premature to move on to decisional documents (BCPs and stand= ards track specifications). Design teams to develop the initial drafts is = an excellent idea, and will certainly be considered. In the end, we will s= till need to build IETF-wide consensus, though. At this stage, I suspect t= he community is more likely to support experimental documents. We would be happy to have input from your students... identifying drafts th= at have security implications and evaluating the impact is critical to the = success of the experiment. We would prefer to have their input funneled th= rough you and your colleague, though. We are being pretty ruthless about l= imiting subscribers to the core team right now. Thanks, Tim Polk On 1/6/11 1:58 PM, "Deirdre Mulligan" wrote: Hi Sean et al Can you tell me what the timeline is on the two below? I am happy to take on some of the evaluation work under 2 and will plan to work it into a lab class I am running this semester looking at policy implications of technical design. On topic 1, I would suggest that we think about other models--both decisional documents, expert committees, etc. -- in addition to the morris draft for iding and working through privacy issues in drafts. thanks and happy new year. cheers deirdre On 1/5/11 6:04 AM, Sean Turner wrote: > Everyone, > > Thanks for agreeing to be in this directorate. The purpose is twofold: > > 1. Provide a place to discuss the Privacy Considerations for Internet > Protocols draft > (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/) > > 2. Test out the recommendations in that draft by reviewing selected draft= s. > > Most that I talked to about this directorate liked the idea that it > would be modeled on the security directorate. To do that we'll need a > secretary to review the upcoming IESG telechat agenda > (https://datatracker.ietf.org/iesg/agenda/documents/), select drafts to > review, and assign drafts to reviewers. What that means is that we'll > actually need people to review drafts and send their comments to the > directorate. The workload will, I think, at most be one draft a month > per person. Now there are only 15 or so, but we've had 30 requests to > join the directorate. So, the workload could actually drop. > > I've gotten at least one recommendation for a secretary and Tim and I > will see if they'd be game. I suspect the assignment process will happen > by generating the list of directorate reviewers and then just working > through the list. > > Tim and I had picked out two drafts that seemed bang on appropriate for > the directorate to review: > > https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ > > and > > https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ > > Tim and I both have some initial comments on the httpstate-cookie draft. > You can see them by clicking on the IESG evaluation tab in he > datatracker. If you think we've missed something please send email to > this list. > > Nick Mathewson provided Tim and I with some comments on the ipfix-anon > draft which I will forward shortly to the mailing list. > > Cheers, > > spt > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir -- Deirdre K. Mulligan Assistant Professor School of Information UC Berkeley dkm@ischool.berkeley.edu 510.642.0499 _______________________________________________ privacydir mailing list privacydir@ietf.org https://www.ietf.org/mailman/listinfo/privacydir --_000_C951DC9A1D404wpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [privacydir] getting things started Hi Deirdre,

There is no fixed timeline on any of this - this is more of an experiment. =  We can’t take more concrete steps, like a BCP that adds privacy= considerations to the required scope of Security Considerations, until we = build rough consensus that the experiment worked.  There are certainly= other holes to fill, but Sean and I see this as the low hanging fruit in t= he frighteningly complex privacy space.

It is probably premature to move on to decisional documents (BCPs and stand= ards track specifications).  Design teams to develop the initial draft= s is an excellent idea, and will certainly be considered.  In the end,= we will still need to build IETF-wide consensus, though.  At this sta= ge, I suspect the community is more likely to support experimental document= s.

We would be happy to have input from your students... identifying drafts th= at have security implications and evaluating the impact is critical to the = success of the experiment.  We would prefer to have their input funnel= ed through you and your colleague, though.  We are being pretty ruthle= ss about limiting subscribers to the core team right now.

Thanks,

Tim Polk


On 1/6/11 1:58 PM, "Deirdre Mulligan" <dkm@ischool.berkeley.edu> wrote:

Hi Sean et al
Can you tell me what the timeline is on the two below?
I am happy to take on some of the evaluation work under 2 and will plan
to work it into a lab class I am running this semester looking at policy implications of technical design.

On topic 1, I would suggest that we think about other models--both
decisional documents, expert committees, etc. -- in addition to the
morris draft for iding and working through privacy issues in drafts.

thanks and happy new year.
cheers
deirdre

On 1/5/11 6:04 AM, Sean Turner wrote:
> Everyone,
>
> Thanks for agreeing to be in this directorate. The purpose is twofold:=
>
> 1. Provide a place to discuss the Privacy Considerations for Internet<= BR> > Protocols draft
> (https://datatracker.ietf.org/doc/draft-morris-privacy-consider= ations/)
>
> 2. Test out the recommendations in that draft by reviewing selected dr= afts.
>
> Most that I talked to about this directorate liked the idea that it > would be modeled on the security directorate. To do that we'll need a<= BR> > secretary to review the upcoming IESG telechat agenda
> (https= ://datatracker.ietf.org/iesg/agenda/documents/), select drafts to
> review, and assign drafts to reviewers. What that means is that we'll<= BR> > actually need people to review drafts and send their comments to the > directorate. The workload will, I think, at most be one draft a month<= BR> > per person. Now there are only 15 or so, but we've had 30 requests to<= BR> > join the directorate. So, the workload could actually drop.
>
> I've gotten at least one recommendation for a secretary and Tim and I<= BR> > will see if they'd be game. I suspect the assignment process will happ= en
> by generating the list of directorate reviewers and then just working<= BR> > through the list.
>
> Tim and I had picked out two drafts that seemed bang on appropriate fo= r
> the directorate to review:
>
> https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/
>
> and
>
> ht= tps://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/
>
> Tim and I both have some initial comments on the httpstate-cookie draf= t.
> You can see them by clicking on the IESG evaluation tab in he
> datatracker. If you think we've missed something please send email to<= BR> > this list.
>
> Nick Mathewson provided Tim and I with some comments on the ipfix-anon=
> draft which I will forward shortly to the mailing list.
>
> Cheers,
>
> spt
> _______________________________________________
> privacydir mailing list
> privacydir@ietf.org
> https://w= ww.ietf.org/mailman/listinfo/privacydir

--
Deirdre K. Mulligan

Assistant Professor

School of Information

UC Berkeley

dkm@ischool.berkeley.edu

510.642.0499

_______________________________________________
privacydir mailing list
privacydir@ietf.org
https://www.ie= tf.org/mailman/listinfo/privacydir

--_000_C951DC9A1D404wpolknistgov_-- From fluffy@cisco.com Tue Jan 11 21:03:00 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B9F28C0E7 for ; Tue, 11 Jan 2011 21:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx8QARwsfh89 for ; Tue, 11 Jan 2011 21:02:59 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5BE1A28C0E3 for ; Tue, 11 Jan 2011 21:02:59 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4GAIfFLE2rR7Ht/2dsb2JhbACWKo4Rc6NBmHKFTASEZ4YlgyA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2011 05:05:17 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0C55FlF027858 for ; Wed, 12 Jan 2011 05:05:16 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Cullen Jennings In-Reply-To: <4D24B772.3060703@ieca.com> Date: Tue, 11 Jan 2011 22:06:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68CD70B0-8242-4AEE-ABED-3A975002A19D@cisco.com> References: <4D24B772.3060703@ieca.com> To: privacydir@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [privacydir] Fwd: I-D Action:draft-koenig-privicons-01.txt X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 05:03:00 -0000 Anyone know which email list is being used to discuss this draft? On Jan 5, 2011, at 11:24 AM, Sean Turner wrote: > I see that some of you were involved in this. In case you weren't = aware of the draft, there's a link below to it. >=20 > spt >=20 > -------- Original Message -------- > Subject: I-D Action:draft-koenig-privicons-01.txt > Date: Wed, 05 Jan 2011 09:00:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Privacy Preferences for E-Mail Messages > Author(s) : U. Koenig, J. Schallaboeck > Filename : draft-koenig-privicons-01.txt > Pages : 17 > Date : 2011-01-05 >=20 > This document proposes a syntax and semantics as an extension of the > Internet Message Format (e-mail message) allowing a Sending User of > an e-mail message to express his or her preference for how the > message content is to be handled by the Receiving Users. For this > purpose, semantics of sets of different character combinations > ("Privicons") are described. These can syntactically be integrated > either in the first-line of the body, in the subject line and/or in a > dedicated header of any e-mail message. The Privicosns icon set > consists of six different icons. They'll be machine readable. The > Privicons concept is partly borrowing its approach from the concept > of emoticons. For example, to express that the content may be > forwarded and even be published. The Sending User could use the > Privicon "[>]", which may be followed by an additional explanations, > such as "please share". >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-koenig-privicons-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir From acooper@cdt.org Wed Jan 12 02:17:54 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AB03A6A20 for ; Wed, 12 Jan 2011 02:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWWlTGkDvYDX for ; Wed, 12 Jan 2011 02:17:52 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 692013A6A1E for ; Wed, 12 Jan 2011 02:17:52 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 12 Jan 2011 05:20:09 -0500 Message-Id: From: Alissa Cooper To: Cullen Jennings In-Reply-To: <68CD70B0-8242-4AEE-ABED-3A975002A19D@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Jan 2011 10:20:05 +0000 References: <4D24B772.3060703@ieca.com> <68CD70B0-8242-4AEE-ABED-3A975002A19D@cisco.com> X-Mailer: Apple Mail (2.936) Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D Action:draft-koenig-privicons-01.txt X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 10:17:54 -0000 I don't think it has been discussed anywhere as of yet. The draft was presented in the app area open meeting at IETF 78. On Jan 12, 2011, at 5:06 AM, Cullen Jennings wrote: > > Anyone know which email list is being used to discuss this draft? > > On Jan 5, 2011, at 11:24 AM, Sean Turner wrote: > >> I see that some of you were involved in this. In case you weren't >> aware of the draft, there's a link below to it. >> >> spt >> >> -------- Original Message -------- >> Subject: I-D Action:draft-koenig-privicons-01.txt >> Date: Wed, 05 Jan 2011 09:00:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Privacy Preferences for E-Mail Messages >> Author(s) : U. Koenig, J. Schallaboeck >> Filename : draft-koenig-privicons-01.txt >> Pages : 17 >> Date : 2011-01-05 >> >> This document proposes a syntax and semantics as an extension of the >> Internet Message Format (e-mail message) allowing a Sending User of >> an e-mail message to express his or her preference for how the >> message content is to be handled by the Receiving Users. For this >> purpose, semantics of sets of different character combinations >> ("Privicons") are described. These can syntactically be integrated >> either in the first-line of the body, in the subject line and/or in a >> dedicated header of any e-mail message. The Privicosns icon set >> consists of six different icons. They'll be machine readable. The >> Privicons concept is partly borrowing its approach from the concept >> of emoticons. For example, to express that the content may be >> forwarded and even be published. The Sending User could use the >> Privicon "[>]", which may be followed by an additional explanations, >> such as "please share". >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-koenig-privicons-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > Part.txt>_______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir > > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From acooper@cdt.org Thu Jan 13 02:36:51 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF5B3A6B63 for ; Thu, 13 Jan 2011 02:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q6qG-ZdvnF0 for ; Thu, 13 Jan 2011 02:36:50 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 52EFF3A6B60 for ; Thu, 13 Jan 2011 02:36:49 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 13 Jan 2011 05:39:00 -0500 Message-Id: From: Alissa Cooper To: Sean Turner In-Reply-To: <4D278269.4010509@ieca.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Jan 2011 10:38:57 +0000 References: <4D247A58.3070605@ieca.com> <4D2610E8.5060105@ischool.berkeley.edu> <4D278269.4010509@ieca.com> X-Mailer: Apple Mail (2.936) Cc: privacydir@ietf.org Subject: [privacydir] draft-ietf-httpstate-cookie (was Re: getting things started) X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:36:51 -0000 Sean, I took a look at this draft (which I meant to do during IETF last call and unfortunately didn't get to) and both your and Tim's DISCUSSes. I think the privacy points that you raise are spot-on; I have just a couple of further thoughts: -- I think it makes sense to make some recommendation on limiting cookie lifetimes. One way to do it without picking a number would be to say that cookies should be set to expire when they are no longer needed by the server for the purpose for which they were set. That way a limit is recommended but it's still fungible. It might also make sense to recommend that cookies lifetimes be reasonable given the expected lifetime of browsers and devices (i.e., a 30-year lifetime makes no sense when people cycle through devices every year or couple of years). -- It's my understanding that most private browsing modes prevent third-party cookies from being read and treat all newly set cookies as session cookies (see http://cdt.org/files/pdfs/ 20101209_browser_rpt.pdf page 9). So I think this is actually covered by the text in 7.2. Does it make sense for you to convey these comments to Adam, or should I post them to the http-state list? Alissa On Jan 7, 2011, at 9:15 PM, Sean Turner wrote: > The two drafts below were on yesterday's IESG telechat. > > For the ipfix-anon draft, I submitted Nick's comments pretty much in > their entirety. I haven't heard from the authors. There's > essentially still time if somebody uncovers something horrible. The > time frame for anything on that draft is at best two weeks. > > For the cookie draft, time is short - actually technically it's over > because IETF LC ended a while ago. The author is very responsive > too. If you've got any comments I need them as soon as possible and > unfortunately there's no guarantee the author will incorporate them. > > This just goes to show we need a secretary to ride herd on us. > > spt > > On 1/6/11 1:58 PM, Deirdre Mulligan wrote: >> Hi Sean et al >> Can you tell me what the timeline is on the two below? >> I am happy to take on some of the evaluation work under 2 and will >> plan >> to work it into a lab class I am running this semester looking at >> policy >> implications of technical design. >> >> On topic 1, I would suggest that we think about other models--both >> decisional documents, expert committees, etc. -- in addition to the >> morris draft for iding and working through privacy issues in drafts. >> >> thanks and happy new year. >> cheers >> deirdre >> >> On 1/5/11 6:04 AM, Sean Turner wrote: >>> Everyone, >>> >>> Thanks for agreeing to be in this directorate. The purpose is >>> twofold: >>> >>> 1. Provide a place to discuss the Privacy Considerations for >>> Internet >>> Protocols draft >>> (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/ >>> ) >>> >>> 2. Test out the recommendations in that draft by reviewing selected >>> drafts. >>> >>> Most that I talked to about this directorate liked the idea that it >>> would be modeled on the security directorate. To do that we'll >>> need a >>> secretary to review the upcoming IESG telechat agenda >>> (https://datatracker.ietf.org/iesg/agenda/documents/), select >>> drafts to >>> review, and assign drafts to reviewers. What that means is that >>> we'll >>> actually need people to review drafts and send their comments to the >>> directorate. The workload will, I think, at most be one draft a >>> month >>> per person. Now there are only 15 or so, but we've had 30 requests >>> to >>> join the directorate. So, the workload could actually drop. >>> >>> I've gotten at least one recommendation for a secretary and Tim >>> and I >>> will see if they'd be game. I suspect the assignment process will >>> happen >>> by generating the list of directorate reviewers and then just >>> working >>> through the list. >>> >>> Tim and I had picked out two drafts that seemed bang on >>> appropriate for >>> the directorate to review: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >>> >>> and >>> >>> https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >>> >>> Tim and I both have some initial comments on the httpstate-cookie >>> draft. >>> You can see them by clicking on the IESG evaluation tab in he >>> datatracker. If you think we've missed something please send email >>> to >>> this list. >>> >>> Nick Mathewson provided Tim and I with some comments on the ipfix- >>> anon >>> draft which I will forward shortly to the mailing list. >>> >>> Cheers, >>> >>> spt >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From turners@ieca.com Thu Jan 13 07:16:50 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60353A69B9 for ; Thu, 13 Jan 2011 07:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKggwEuvdiau for ; Thu, 13 Jan 2011 07:16:49 -0800 (PST) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by core3.amsl.com (Postfix) with SMTP id 60EE33A6892 for ; Thu, 13 Jan 2011 07:16:49 -0800 (PST) Received: from [98.139.52.189] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jan 2011 15:19:09 -0000 Received: from [98.139.52.139] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jan 2011 15:19:09 -0000 Received: from [127.0.0.1] by omp1022.mail.ac4.yahoo.com with NNFMP; 13 Jan 2011 15:19:08 -0000 X-Yahoo-Newman-Id: 991241.45366.bm@omp1022.mail.ac4.yahoo.com Received: (qmail 30546 invoked from network); 13 Jan 2011 15:19:08 -0000 Received: from thunderfish.local (turners@96.241.0.234 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 13 Jan 2011 07:19:08 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: .RZY8p0VM1nauDQ8.bnqzU3_93Q7do7AgtF9wQcBc16GPji juCu9n7e9YZAsD1dcJziTwNJLOBCr.qGwQ2ZepVq3UsQIoJ4tQpu98N4O4wy HDG3GZOP1UTwFl7y8kqYwwdmj0GQYZXkq44QTZ6Eyl.DZffTIlNJqRmQ4HQ6 fRJbmy.IPLEex4a.JrYF.aI1fVoq6ycaqdFny5DKLmb9a3v2IdcZSHHyIK.t SSRdyFL0LrjAJ69l9.1BGQZRz1eBi3UN9YRbUSwgAWjIHRgL8uXk5hYZhw7E R_yv4be7dcBPXWl4Uo6UaKhuJUkxrBx5B X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D2F17EC.2060706@ieca.com> Date: Thu, 13 Jan 2011 10:19:08 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alissa Cooper References: <4D247A58.3070605@ieca.com> <4D2610E8.5060105@ischool.berkeley.edu> <4D278269.4010509@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] draft-ietf-httpstate-cookie (was Re: getting things started) X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:16:50 -0000 I'm perfectly happy having you send them directly to Adam. spt On 1/13/11 5:38 AM, Alissa Cooper wrote: > Sean, > > I took a look at this draft (which I meant to do during IETF last call > and unfortunately didn't get to) and both your and Tim's DISCUSSes. I > think the privacy points that you raise are spot-on; I have just a > couple of further thoughts: > > -- I think it makes sense to make some recommendation on limiting cookie > lifetimes. One way to do it without picking a number would be to say > that cookies should be set to expire when they are no longer needed by > the server for the purpose for which they were set. That way a limit is > recommended but it's still fungible. It might also make sense to > recommend that cookies lifetimes be reasonable given the expected > lifetime of browsers and devices (i.e., a 30-year lifetime makes no > sense when people cycle through devices every year or couple of years). > > -- It's my understanding that most private browsing modes prevent > third-party cookies from being read and treat all newly set cookies as > session cookies (see http://cdt.org/files/pdfs/20101209_browser_rpt.pdf > page 9). So I think this is actually covered by the text in 7.2. > > Does it make sense for you to convey these comments to Adam, or should I > post them to the http-state list? > > Alissa > > On Jan 7, 2011, at 9:15 PM, Sean Turner wrote: > >> The two drafts below were on yesterday's IESG telechat. >> >> For the ipfix-anon draft, I submitted Nick's comments pretty much in >> their entirety. I haven't heard from the authors. There's essentially >> still time if somebody uncovers something horrible. The time frame for >> anything on that draft is at best two weeks. >> >> For the cookie draft, time is short - actually technically it's over >> because IETF LC ended a while ago. The author is very responsive too. >> If you've got any comments I need them as soon as possible and >> unfortunately there's no guarantee the author will incorporate them. >> >> This just goes to show we need a secretary to ride herd on us. >> >> spt >> >> On 1/6/11 1:58 PM, Deirdre Mulligan wrote: >>> Hi Sean et al >>> Can you tell me what the timeline is on the two below? >>> I am happy to take on some of the evaluation work under 2 and will plan >>> to work it into a lab class I am running this semester looking at policy >>> implications of technical design. >>> >>> On topic 1, I would suggest that we think about other models--both >>> decisional documents, expert committees, etc. -- in addition to the >>> morris draft for iding and working through privacy issues in drafts. >>> >>> thanks and happy new year. >>> cheers >>> deirdre >>> >>> On 1/5/11 6:04 AM, Sean Turner wrote: >>>> Everyone, >>>> >>>> Thanks for agreeing to be in this directorate. The purpose is twofold: >>>> >>>> 1. Provide a place to discuss the Privacy Considerations for Internet >>>> Protocols draft >>>> (https://datatracker.ietf.org/doc/draft-morris-privacy-considerations/) >>>> >>>> 2. Test out the recommendations in that draft by reviewing selected >>>> drafts. >>>> >>>> Most that I talked to about this directorate liked the idea that it >>>> would be modeled on the security directorate. To do that we'll need a >>>> secretary to review the upcoming IESG telechat agenda >>>> (https://datatracker.ietf.org/iesg/agenda/documents/), select drafts to >>>> review, and assign drafts to reviewers. What that means is that we'll >>>> actually need people to review drafts and send their comments to the >>>> directorate. The workload will, I think, at most be one draft a month >>>> per person. Now there are only 15 or so, but we've had 30 requests to >>>> join the directorate. So, the workload could actually drop. >>>> >>>> I've gotten at least one recommendation for a secretary and Tim and I >>>> will see if they'd be game. I suspect the assignment process will >>>> happen >>>> by generating the list of directorate reviewers and then just working >>>> through the list. >>>> >>>> Tim and I had picked out two drafts that seemed bang on appropriate for >>>> the directorate to review: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >>>> >>>> and >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >>>> >>>> Tim and I both have some initial comments on the httpstate-cookie >>>> draft. >>>> You can see them by clicking on the IESG evaluation tab in he >>>> datatracker. If you think we've missed something please send email to >>>> this list. >>>> >>>> Nick Mathewson provided Tim and I with some comments on the ipfix-anon >>>> draft which I will forward shortly to the mailing list. >>>> >>>> Cheers, >>>> >>>> spt >>>> _______________________________________________ >>>> privacydir mailing list >>>> privacydir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/privacydir >>> >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> > > > From turners@ieca.com Thu Jan 20 05:25:01 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9E93A7118 for ; Thu, 20 Jan 2011 05:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auYUggZISYjv for ; Thu, 20 Jan 2011 05:24:59 -0800 (PST) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by core3.amsl.com (Postfix) with SMTP id ACFCF3A6DAA for ; Thu, 20 Jan 2011 05:24:59 -0800 (PST) Received: from [98.139.91.69] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 13:27:40 -0000 Received: from [98.139.91.53] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 13:27:40 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 13:27:40 -0000 X-Yahoo-Newman-Id: 50451.96169.bm@omp1053.mail.sp2.yahoo.com Received: (qmail 85065 invoked from network); 20 Jan 2011 13:27:40 -0000 Received: from thunderfish.local (turners@71.191.14.145 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 20 Jan 2011 05:27:39 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: EDT6clEVM1kH7ziyiixUDZQ0_rsH4UNitcfNHcWWD.ANSpL 4uIP0TQOw3AiPYOS.H0YTOEKfQSD4rJszStkJ2U47wSMa8aoLj8Z.DWb8PdY d9.khmlIe2TS4hzEhX1oxwJnywC5ntT2xa6LcNK5hKFKSbtaYosBBLiYi7wS ZUL9neT03HdbqiqSf91jTrswfYouT093VJSKUA9Qh3qceL4OwjAdGYZS6uUV UMCzQtzoGC35kBR.0Judf3tvzR9._gG78xC4O5ZOlc1vyTntR1r1QkT1soIx kAFit5TRtCsxzie9zb8KX4hLEfNA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D3837F9.2030807@ieca.com> Date: Thu, 20 Jan 2011 08:26:17 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: privacydir@ietf.org References: <20110106160145.18680.61661.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [privacydir] Sean Turner's Discuss on draft-ietf-ipfix-anon-05: (with DISCUSS and COMMENT) X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:25:01 -0000 I logged a lengthy DISCUSS against this draft based on Nick's comments. Here's the diffs from the old version: Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-anon-06 I haven't yet had a chance to review the changes to confirm that they actually addressed the comments. I did however want everyone to see that there's been some impact. Thanks for the review Nick. spt On 1/20/11 5:52 AM, Brian Trammell wrote: > Hi, Sean, all, > > We have just posted an -06 revision of the ipfix-anon draft, which we believe addresses all these issues. > > Best regards, > > Brian > > On Jan 6, 2011, at 5:01 PM, Sean Turner wrote: > >> Sean Turner has entered the following ballot position for >> draft-ietf-ipfix-anon-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> #1) General >> >> The discussion and definition of 'anonymization' here may be the one more usually used when referring to data flows, but there are larger fields at work here that it might be a good idea to harmonize with. The idea of deleting fields or aggregating records in a data set is more closely associated with the topic of inference control (see also work on "k-anonymity"). For these, the Inference Control subsection of Ross Anderson's "Security Engineering" is a reasonably good introduction. The idea of anonymity in general seems more closely tied to notions of untraceability and unlinkability; for those see Pfitzmann and Hansen "A terminology for talking about privacy by data minimization". It's no disaster (and certainly not unprecedented!) to have the meaning of "anonymize" be context-dependent, but it _is_ important to say what property you actually mean to achieve thereby. >> >> It would also be useful to note that this draft _only_ considers the kind of inference control you can achieve through transformation of individual flow records. Aggregation-based anonymization is not considered --and not even included in this draft's definition of anonymization!-- even though it provides more robust privacy results. >> >> #2) Section 3 >> >> So it seems that the goal of anonymization, as stated here, is to prevent IP flow data from being traced to the networks, hosts, or users that participated it. But this is only one possible goal of these techniques. >> >> Other uses of the anonymization techniques in this draft include: >> >> - One-way untraceability. Under some circumstances, it is fine >> to identify the originator/recipient of a given flow, but not >> both. For example, it might be fine to identify users so long >> as the services they use can't be inferred, and it might be >> fine to identify servers so long as you can't tell who their >> users are. >> >> - Resistance to partner profiling. Even if no particular flow can >> be linked to a particular entity, it might be undesirable for >> the set of flows as a whole to be useful for statistically >> inferring certain properties of networks, hosts, or users. For >> example, even if an attacker can trace no specific flow to >> users Alice and Bob with confidence greater than 0.01%, if they >> could nevertheless infer that Alice and Bob communicate >> regularly with P=99%, Alice and Bob would reasonably consider >> their privacy to have been compromised. >> >> For a more rigorous of an attack that achieves profiling without >> tracing specific interactions, see Danezis's Statistical >> Disclosure attack. >> >> - Non-observability. It might be undesirable for a flow or set >> of flows to confirm that a particular entity was in fact >> present or absent at a given time. >> >> Some related desirable properties include: >> >> - Non-linkability. It might be undesirable for two flows >> generated by the same entity to be linked to one another. >> Linkability between flows is a strong amplifier for traceability >> attacks: if through mischance, misdesign, or external >> knowledge, an adversary manages to trace a single flow to one >> of its entities, then linkability between flows means that >> _all_ of that entity's flows are now traced. >> >> Website Fingerprinting ("Fingerprinting Websites Using Traffic >> Analysis", Andrew Hintz, 2002) is an example of a more subtle >> attack enabled by flow linkability. >> >> - Ccorrelation resistance. It might be undesirable for >> anonymized flows processed by different IPFIX installations to >> be correlated to one another. For example, suppose that the >> same flow is anonymized one way as it travels through network >> A, and another way as it travels through network B. It might >> be the case that neither anonymized flow on its own has enough >> information to identify a user, but that both flows, taken >> together, can identify the user. If this is so, and an attacker >> might see both anonymized flows, then it becomes critical to >> ensure that the adversary cannot easily learn that the two >> anonymized flows refer to the same flow. >> >> I'm not proposing that every IPFIX user should want all of these properties under all circumstances, but without them, the untraceability properties become more fragile and much harder to achieve. >> >> It seems that elsewhere in the document, requirements _like_ these are considered, though they're usually not explicit. Instead, the document only says that certain properties that are not themselves identifiers "can be used to identify hosts and users" without much considering how in some cases. >> >> #3) Section 3 >> >> (Perhaps this applies better to the security consideration section. Either way, without a discussion of known attacks against entities' privacy, it's hard to have a meaningful discussion of how privacy can be achieved.) >> >> Privacy, like security, requires us to consider threat models. In other words, we need to state our privacy requirements in terms of an attacker's resources, and what count as a successful attack. The part of this draft that worries me most is that, when discussing "untraceability", it does so with no actual explicit attacker in mind. >> >> Because there isn't an explicit threat model or collection of threat models, it's not really possible to say whether some of the attacks and caveats below are really "valid" attacks against their anonymization methods, because "without an treat model, there are no vulnerabilities--only surprising features." >> >> For example, some places in the draft discuss "traffic injection" attacks, implying an active attacker. But other places in the draft claim that anonymization techniques are effective when they _do not_ resist an active attacker. >> >> #4) Section 4 >> >> Throughout this section, it seems potentially misleading to say what various anonymization techniques are "intended to defeat", and so on. A naive reader could take this to mean that a technique _actually does_ defeat one of these attacks, or that it _actually will_ provide a given degree of privacy, which I think is not what the authors are trying to say. >> >> On the other hand, if this draft _is_ trying to say which techniques achieve what, then it needs to be much, much more specific about the threat models and circumstances for which its statements are true. >> >> #5) Section 4.1.3 >> >> We should say something about the security requirements of the permutation function. There is all the difference in the world between, say, a block cipher and an xor with a known constant, but this section doesn't actually make that distinction. Below, insection 5.4, the draft says that the permutation and its parameters SHOULD not be exported, but that's not quite the same as saying that the permutation SHOULD be hard to invert without knowing its parameters. >> >> Similarly, the recommendation to use a hash function can fail badly if the hash function is known to the attacker: it is trivial for the attacker to brute force all IPv4 addresses to deanonymize subjects if a known hash is used. HMAC with a secret key would be more appropriate. >> >> #6) Section 4.3.2 >> >> You should note that an active attacker who can create recognizable flows can turn an enumerated timestamp dataset into a precision-degraded dataset by periodically injecting a recognizable flow. >> >> #7) Section 4.3.3 >> >> You should note that adding a uniform random shifts is remarkably fragile: if the adversary can identify the correct time for even one flow, he can learn the times for all other flows. Worse, if datasets are generated continuously, with each one starting right after the previous one finishes, then the attacker who knows the shift for one dataset can place bounds about the shifts for all close-in-time datasets by induction. >> >> #8) Section 5.3& 5.4 >> >> Statements to the effect of "Information about [the particular anonymization technique used] SHOULD NOT be exported" are a total violation of Kerckhoffs' principle: the security of a system should depend only on the secrecy of key-like parameters, not on the secrecy of its algorithms. >> >> In practice, after all, any competent attacker will know which permutation functions and binning functions are implemented by the popular IPFIX vendors. Any aspect of permutation/binning which the attacker must not learn needs be keyed with a secret key that can be changed locally. >> >> #9) Section 9 >> >> A risk that it could be worthwhile to mention: Frequently, anonymized data will be treated by administrators as "not >> privacy-sensitive" when in fact it should only be treated as "less privacy-sensitive." (For examples in other fields, see the results concerning user reidentification from AOL's search terms, or Netflix film queues.) The anonymization techniques described here do indeed make entities associated with flows harder to trace ... but there is a risk that when they are applied, administrators will treat flow data as "completely safe" when in fact it has only become "less harmful if misused". >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> #1) General >> >> The authors should decide whether they're going to use American or British spellings. The draft uses the American spellings for categorize, organize, minimize, behavior, and so on, but unaccountably uses the British "-ise" in anonymise and pseudonymise. In the research literature, and in the other relevant RFCs, "anonymize" seems to be more popular, but either spelling type is fine so long as it's consistent. >> >> #2) Section 1 >> >> It might be wise to repeat here (or even in the abstract) the note from the Security Considerations section that this draft is only meant to explain how to interchange anonymized data, not to provide any recommendations as to which anonymization techniques to use, or even any guarantee that any particular technique achieves any particular purpose. Otherwise, it is easy to misread some parts of section 4 as promising that particular techniques will prevent particular attacks, which is not in fact the case for reasonable threat models. >> >> #3) Section 4.2 >> >> Brute-forcing a 48-bit MAC addresses is harder than brute-forcing a 32-bit IPv4 address, but not out of reach even for a hobbyist. >> >> #4) Section 4.3 >> >> There is existing research on the extent to which the beginning and ending times of related flows can be used to link an anonymized view of a flow to a non-anonymized view of the flow. Can we add a pointer to Murdoch and Zelinski's "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries". [ http://petworkshop.org/2007/papers/PET2007_preproc_Sampled_traffic.pdf ] >> >> #5) Section 4.3& 4.4 >> >> There is a pretty extensive literature about the extent to which perturbing timing and volume information prevents correlation, linkability, and website fingerprinting. Check out the traffic analysis section of freehaven.net/anonbib, and also check out the literature on "stepping stone detection". >> >> The results are unintuitive to many people; in general, to resist correlation and linkability attacks, you need to use perturbations of higher-variance or bins of larger size than many implementors would expect. >> >> Seems like there should be a reference added to these. > >