Re: [ietf-privacy] New Webiquette RFC
This submission raises an interesting question for the IETF: how to treat anonymous (or pseudonymous) submissions? On one hand, there are lots of classic reasons for hiding behind a pseudonym when participating in public discussions. On the other hand, the IETF has to be protected against intellectual property issues and against sabotage by external groups. Before submissions are accepted for publication, their authors have to disclose whether they, or their employer, own intellectual property rights on the technologies described in the draft. Failure to disclose would influence the prosecution of intellectual property disputes that might arise when third parties implement the technology. This provides some degree of protection to implementers. But when the submission cannot be traced to a specific company, these protections disappear, and we might have a problem. So this is one source of tension between standards and anonymity. The other source of tension is the risk of sabotage. Various groups have tried to sabotage the standard process in the past, for example to delay the deployment of encryption, or to introduce exploitable bugs in security standards -- some of these tactics were exposed in the Snowden revelations. Anonymous participation could allow these groups to perform such sabotage in untraceable ways, which is obviously not desirable. I think this issue of anonymous participation is worth discussing. -- Christian Huitema On 4/17/2022 11:35 AM, kate_9023+...@systemli.org wrote: Dear all, I'm quite new at creating RFCs. I have recently submitted a draft for a new webiquette and I am still searching a group which will take care of it. It would fit into privacy as this new webiquette is dealing with new internet technology such as deepfakes, sharing photos of 3rd parties and so on and also deleting old information on a regular basis good behavior. It's also quite short with only 9 pages and also covers cancel culture and mobbing. I think a document like this is needed and important. Anyone here who'd like to take care or helping me making an RFC out of it? Or guide me in the right direction? The draft can be found here: https://www.ietf.org/archive/id/draft-rfcxml-general-the-new-webiquette-00.txt Best Regards, Kate ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
(Moving this conversation to DNS-SD mailing list) On Thursday, June 23, 2016 2:53 AM, S Moonesamy wrote: > > Hi Tim, > At 05:18 22-06-2016, Tim Chown wrote: > >We're encouraging discussion of privacy considerations in the WG. As a > >result, we now have a draft (see below), including an initial proposal > >for a solution, for which we'd welcome wider review. The draft also > >addresses mDNS/DNS-SD privacy within single subnet scenarios. > > One of the privacy issue identified in the draft (Section 2.4) is device > fingerprinting. In Section 3.1, it is proposed to solve the privacy issues > described in Section 2.1 by obfuscating instance names. If I had to pick one > privacy threat for that I would choose "correlation". Obfuscating service names > would not address that. Section 3 describes an initial design that was then abandoned. I guess that in the next revision we could just remove that section entirely. On the other hand, the proposal was indeed to use different obfuscated names at different locations. > If I understood the draft correctly, the solution "to prevent tracking over time > and location, different string values would be used at different locations, or at > different times". QR-codes are used to generate a shared secret and establish > trust between two or more "friends". The private discovery service relies on pre-existing pairings. The pairing solutions are only drafted in very vague terms in the draft. I really wonder whether we should go define a complete pairing protocol. Is that in-charter for DNS-SD? What about competing with existing solutions over Bluetooth, Wi-Fi, and certainly many more? -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Is there an official working definition for Privacy Online?
On Friday, April 17, 2015, at 9:14 AM, Dave Crocker wrote ... This translates into privacy relates to controlling disclosure of information about a person or organization. Then add the scope-of-control portion. There is indeed some fuzziness in the definition of privacy. I like the analysis in this Pew Research Center study on Public Perceptions of Privacy and Security in the Post-Snowden Era: http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/. I think they do a good job relating threats to privacy and threats to personal security. To quote: Beyond the frequency of individual words, when responses are grouped into themes, the largest block of answers ties to concepts of security, safety, and protection. For many others, notions of secrecy and keeping things 'hidden' are top of mind when thinking about privacy. -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
[ietf-privacy] PPM Review of RFC 1108
This RFC defines an IP header option for security options. The options enable hosts to mark their traffic as belonging to a particular security level. Presumably, secure routers will ensure that traffic marked with a specific security option is contained within a network that meets the corresponding security requirements. The RFC was written in 1988, before we started writing security considerations in RFC. A security consideration section would probably have listed the two major issues with the option, use by unauthorized hosts and use in unsecure networks. If a network allows for traffic from both secure and unsecure sources, unsecure sources can easily insert spoof IP addresses and insert options in the IP header. This could be used for sending attack packets to secure system, despite attempts at compartmenting the network. Ping of death and variants come to mind. A mobile host that is allowed to send secure traffic may inadvertently visit an insecure network. In that case, using the option provides for easy identification of the host as a potential target. Mobile hosts were not common in 1988, and this threat was not envisaged in the RFC. This was then. By now, IP options are very rarely used. The RFC should probably be reclassified as historic. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] PPM Review of RFC 1108
That was my attempt at using the random lottery. I like using the issue page better for input. Also, I prefer reading the html version of the RFC from the IETF tools page. Maybe the lottery should just give you a suggestion of an RFC number… From: ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, May 21, 2014 9:10 PM To: ietf-privacy@ietf.org Subject: [ietf-privacy] PPM Review of RFC 1108 This RFC defines an IP header option for security options. The options enable hosts to mark their traffic as belonging to a particular security level. Presumably, secure routers will ensure that traffic marked with a specific security option is contained within a network that meets the corresponding security requirements. The RFC was written in 1988, before we started writing security considerations in RFC. A security consideration section would probably have listed the two major issues with the option, use by unauthorized hosts and use in unsecure networks. If a network allows for traffic from both secure and unsecure sources, unsecure sources can easily insert spoof IP addresses and insert options in the IP header. This could be used for sending attack packets to secure system, despite attempts at compartmenting the network. Ping of death and variants come to mind. A mobile host that is allowed to send secure traffic may inadvertently visit an insecure network. In that case, using the option provides for easy identification of the host as a potential target. Mobile hosts were not common in 1988, and this threat was not envisaged in the RFC. This was then. By now, IP options are very rarely used. The RFC should probably be reclassified as historic. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Wiki for managing PPM reviews of existing RFCs
If you were at the Monday lunch and announced an intention to working on a particular set of RFCs, now there's a home for your reviews. If you couldn't commit to doing reviews but want to do some, here is your chance! (If you don't have a login on the wiki, it's easy to register.) In both cases, please add a ticket when you _start_ your review -- don't wait until you finish, people will want to know all about it from the start. I added a couple of tickets for the various DHCP RFC that I reviewed when writing the DHCP draft. What is the process for picking new RFC to review? Just pick one at random and write a provisional ticket in https://trac.tools.ietf.org/group/ppm-legacy-review/wiki ? -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
