Fernando, I guess that we are at an impasse again. I just want to make it clear to everyone that this proposed draft of yours doesn't really do anything substantial for privacy issues and I find it misleading to mention privacy in the title. I too am extremely busy and cannot afford to devote any more time debating this issue with you. I had stopped this discussion with you once before but some other people asked me to bring it up with you again. I see that it was for naught. Science is not absolute so what is written can just be some ones opinion based on what was happening at that time. In today's environment privacy has come to the fore front and the parameters that were used to define privacy before have changed greatly. It is a much bigger issue and getting bigger every day.
Hosnieh -----Original Message----- From: Fernando Gont [mailto:[email protected]] Sent: Monday, April 29, 2013 9:56 PM To: Hosnieh Rafiee Cc: 'Mark Smith'; 'Alissa Cooper'; [email protected]; 'Christian Huitema' Subject: Re: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard Hosnieh, Quite a few times I have responded to your comments, and have even provided pointers to publicly-available papers that you seem to have ignored. I disagree with your comments below... but cannot really invest more time in writing responses you'll ignore. This I-D improves at least two privacy related issues, with minimal effort and complexity. That's usually referred to as "engineering". As noted by others and myself in other messages, there are other aspects that might not even be addressable, or that might be undesirable to address for the general case. (e.g., from the pov of privacy you might want to use a new random address for every new flow... but that generally causes a lot of trouble and complexity). That's as much as I will add to this sub-thread. Thanks, Fernando On 04/29/2013 11:23 AM, Hosnieh Rafiee wrote: > Dear Mark > >> So privacy and security are relative, not absolute. I think this >> provides > better privacy compared to the use of MAC addresses for IIDs > > Unfortunately that answer is not exactly true. As I explained in my > last messages, it is really related to the lifetime of the router > prefix. In reality, if you do not change it within a short period of > time, like when a MAC address is used, then an attacker will be able > to obtain enough information about this node in order to prepare > attacks against during the time they use the same IID. Then later, the > attacker will have the opportunity to follow his victim when he goes > to a new network using the information he obtained earlier. This means > that changing the IP address now will be of no use . This is why I do > not see how privacy is enhanced in any way with this way of IID > generation and I keep reiterating that what this draft states about > also providing privacy is not true. This draft is just about the > generation of IID in a manner not based on MAC addresses and offers nothing of value concerning privacy issues. > > Privacy and security are relative, that is true. But the way he wants > to maintain privacy is like someone who hides his head in a hole > hoping that nobody will see him. I do not call this privacy. Privacy > is relative when you make as much effort as possible to keep the data > confidential. If some ingenious attackers can come up with new > approaches to find your data, then this is not your fault. I mean by > this that if one wants to claim that he has enhanced privacy, then he > will have had to do everything possible to prevent the currently > known privacy attacks. But if you cannot accomplish that in your > solution, then you should not mislead readers by saying that your > solution does.. This is because privacy is like a bottle of water, > where your information is the water inside this bottle. It makes no > difference whether you do not close the tap or just don't close it as > tightly as you should (like this draft), The bottle will leak water, > and for some attackers even a few drops is all they need to initiate > further attacks which can result in much damage to the prey. So, if a > draft claim to have privacy, it cannot just say I will consider just > this part of privacy not others. This is why I suggested to him to > just let the users decide on the lifetime for their IP address when > they want to install this feature. In this case, he does not try to do > anything about that bottle; the aim of the draft is not about privacy > but a randomized IID. That way no one will have any expectations for privacy. So, what I am saying here is that having a big title which alludes to privacy enhancements does not make sense. > > >> Can you define the "privacy" you don't think it has any effect on? > I have already answered this by what I said in my prior sentence. > > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
