Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
At 17:55 28/11/2011, Andrew Sullivan wrote: On Mon, Nov 28, 2011 at 05:28:15PM +0100, Francis Dupont wrote: = BTW what is the operational definition of security (just to know)? I think I observed in my original remarks that this is a problem that also happens in discussions of security. That some other topic has such a problem is not a good reason to repeat that problematic structure with privacy. This is why I said this is a typical Wittgensten situation. Not only the problem is (if I read you correctly) a language problem in describing the issue, but now you make the need to resolve the problem a language metaproblem. The Internet architecture has supposedly not initally considered security and we have difficulty enough to add it now: so, not need to add the privacy burden. Your solution is therefore that this privacy issue should not to be addressed within the IETF Internet end to end layers scope. It seems also is the position of Joe Touch (at least until an IETF community consensus has not been reached). However, 1) they also are not considered on the user side. 2) some are considering that privacy is part of security. This means that 1) the proper way to address them is by subsidiarity (on a per national law, corporate practice, personnal need, etc.) and that the proper place where they are to be addressed is at the fringe to fringe IUI layers (Internet/Intelligent Use Interface) 2) we are therefore in a similar architectural configuration as in the IDNA2008 case. As you may recall (my clarification appeals) IESG and IAB made clear these IUI layers were no part of the IETF charter as also to be shared with other convergent technologies, but: - are to be adequately supported on the Internet side (IAB works on IDNs support exploration, as they explore Privacy) - proposed me to start a BOF on the matter - but I am not an IETF engineer and this issue belong to the IUsers emerging community I liaise through the i...@ietf.org (I keep cc'ed) I therefore read you as supporting the idea that IRT. security and privacy issues, things are similar to mapping for languages and scripts. Security and privacy should therefore be addressed by subsidiarity in the context of the Internet use: the Internet protocols having to make sure this IS possible in being definitly stable and clearly documented (like in the DNS case) for the IUI designers to build on them. (At IUse level we consider that the split is through the MUST/SHOULD/MAY sequence, where we read IETF's MUSTs as untangible IS/ARE we can trust). I certainly do support that clarification. jfc ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
At 05:13 28/11/2011, Andrew Sullivan wrote: = it is in the European Convention on Human Rights as a legal principle so there is at least a basis but I am afraid it won't really help. As a (French) lawyer explained to me one day, a legal text must be as less accurate as possible so it can be applied to more than one particular case so a legal principle... You appear to be claiming the in above that we are suppose to write Privacy Considerations without a clear definition of what could possibly be covered, except maybe everything. Andrew, we are to reach a rough consensus. One cannot build a consensus in opposing some of the members. Whatever their motivations. Now, how to do it? The need is not to cover everything, but to cover everything in our bailywick that may affect everything as defined by the obligations of the various national legal cultures. So, the point seems rather simple: to cover our tracks. Whatever privacy may be, the technical matter is about not giving away/leaking undisclosed (meta)data through what we permit to do. So the Internet works better (RFC 3935) not worse. Questions: 1. which information do we use? 2. which information do we introduce? 3. in which way do/canwe expose them? 4. which steps do we already take not to (over)expose them? 5. are there additional step we could consider to cover our tracks? If the responses do not gain the support of every people (for whatever reason) there will not be a consensus and nothing will be published. jfc Ok, here's more boilerplate for you: Privacy Considerations This document may affect the privacy of someone on the Internet, according to the definition of privacy in your jurisdiction. You are encouraged to consider that. That's all we can say, AFAICT from your response. PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights (see the article 8 about privacy). Yes, of course. We should base new policies on the official opinion of all the people who can be bothered to work on Wikipedia articles. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. = I clarified my objection to the nat-reveal document: I really want to get it with a privacy considerations section and I have no technical concerns about it (i.e., even I don't like the methods it describes I share the idea to not leave ISPs invent their own shaky methods). Based on input from a directorate that is proposed in a doc that is still a draft. = it doesn't matter as soon as we can put a name on it (i.e., what matters is the result, there is no need to fix the process first when we can get it). The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. = perhaps but the idea is to enforce authors to not ignore the question. It worked well for security which at its time was far to be easy too. So IMHO it is the hard but right way, i.e., without this we can get documents with a real impact on privacy but no argument about it (and I am afraid you are contributing to prove this :-). Regards francis.dup...@fdupont.fr PS: I propose to use our energy to other things... ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Hi Francis, -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de Francis Dupont Envoyé : lundi 28 novembre 2011 14:00 À : Joe Touch Cc : int-area@ietf.org Objet : Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting In your previous mail you wrote: Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. = I clarified my objection to the nat-reveal document: I really want to get it with a privacy considerations section and I have no technical concerns about it (i.e., even I don't like the methods it describes I share the idea to not leave ISPs invent their own shaky methods). As you know there is already a Privacy Section in the document: http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2 I know it is incomplete but I really would like to capture the privacy concerns you have in that section. Thanks. Cheers, Med ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: As a preliminary note, I will suggest to you that your quoting conventions ... = as I can't see a difference between mine and yours I suggest to address this in private. This claim requires an adequate operationalization of privacy. What exactly does one mean by this? Most of the claims I hear about it, including a number of the windy assertions that there is a fundamental right (whatever that is) to it, seem never to state what exactly it is supposed to mean. = it is in the European Convention on Human Rights as a legal principle so there is at least a basis but I am afraid it won't really help. As a (French) lawyer explained to me one day, a legal text must be as less accurate as possible so it can be applied to more than one particular case so a legal principle... = I (mis?)interpreted your message as asking for a formal definition of the term privacy so I tried to answer. PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights (see the article 8 about privacy). Yes, of course. We should base new policies on the official opinion of all the people who can be bothered to work on Wikipedia articles. = you are free to follow the pointer to the text itself and not stop at the comments which, I agree, can't be blindly assume as impartial. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: As you know there is already a Privacy Section in the document: http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2 = you refer to this statement: The HOST_ID does not reveal more privacy information than what the source IP address does in a non-shared address environment if it is not false it is very far to be complete: the HOST_ID (and other methods) should be compared to a shared address environment without HOST_ID (and any other method) too. I know it is incomplete but I really would like to capture the privacy concerns you have in that section. = it should be fine to explain the IETF doesn't endorse the use of this, etc. I leave the wording to better skilled people, the idea is: the document explains if you have to do it, you should do it this way and no more. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Mon, Nov 28, 2011 at 02:36:45PM +0100, Francis Dupont wrote: = I (mis?)interpreted your message as asking for a formal definition of the term privacy so I tried to answer. I think I said I wanted an operational definition, which while perhaps more or less formal always provides all the necessary and sufficient conditions for something to qualify under the term. The definition you proffered (you seemed to say) you understood to be ambiguous. If it's ambiguous, then it cannot possibly be an operational definition (or anyway, not a good one). So it doesn't meet the need, and I therefore think we can't add a Privacy Considerations section to documents (yet). Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 11/28/2011 4:59 AM, Francis Dupont wrote: The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. = perhaps but the idea is to enforce authors to not ignore the question. It worked well for security which at its time was far to be easy too. It worked *after* the requirement for a security considerations section was agreed by the IETF. That is not yet the case with privacy considerations. ... PS: I propose to use our energy to other things... I plan to use mine raising concerns with the IAB's soapbox on this issue. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: On Mon, Nov 28, 2011 at 02:36:45PM +0100, Francis Dupont wrote: = I (mis?)interpreted your message as asking for a formal definition of the term privacy so I tried to answer. I think I said I wanted an operational definition = BTW what is the operational definition of security (just to know)? Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Mon, Nov 28, 2011 at 05:28:15PM +0100, Francis Dupont wrote: = BTW what is the operational definition of security (just to know)? I think I observed in my original remarks that this is a problem that also happens in discussions of security. That some other topic has such a problem is not a good reason to repeat that problematic structure with privacy. A -- Andrew Sullivan a...@anvilwalrusden.com ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Suresh, May I suggest that once again Witgestein is right: we are confronted to a philosophical issue through a technical problem (and vice-versa), and the reason why is that the problem cannot be solved in the way it is posed and therefore discussed. This is the IETF. So the question is to understand what (network) privacy specifically is at the IETF layer (not what it may mean in general to IETF people in particular). Then to make sure that this (presupposed: I suppose that no one opposes?) mandatory IETF privacy support is insured at IETF layers in a cooperative way with layers below and above, and that the adopted strategy is documented in a privacy section. The IAB draft is a draft. The Int-area debate is an experimental case for that I_D. And reprocically. I understand that Francis only want a waste of time, the need for an exhausting opposition and a further demotivation if the debate does not engage in a direction where the European prerequisite (which has equivalent throughout the whole world) can be respected The ietf-privacy non-WG mailing list (Issues related to privacy that cut across multiple groups and areas. The initial goal of this discussion is to investigate privacy and related identity management terminology) has the draft: http://tools.ietf.org/html/draft-hansen-privacy-terminology-03 with changes interesting to consider from its http://tools.ietf.org/html/draft-hansen-privacy-terminology-02 previous version. What I feel from the pieces I gathered for IUCG discussion at http://iucg.org/wiki/Privacy is that security - as IETF understands it - is end to end oriented, while privacy is content oriented. This may mean that a privacy section could result from two subsections (network, content) of the security section. I would not be JFC if I did not add that a third impermeability (to context) subsection should consider the multilingual, architectural, interapplication, etc. aspects that might possibly interfere. A connex security/privacy/permeability issue is neutrality. I checked: the string neutra neither appears in the tables of: - WG list: http://datatracker.ietf.org/wg/, - non-WG list: http://www.ietf.org/list/nonwg.html - nor in the concluded WG list: http://www.ietf.org/wg/concluded/. I tend to define network neutrality as the end to end/fringe to fringe service staying unchanged by the change of its component, I feel there are many ways in which neutrality may concur to network security, privacy and impermeability. jfc At 08:23 27/11/2011, Suresh Krishnan wrote: I think part of the confusion surrounding this draft arises because of the apparent discrepancy between the stated goal of the draft and the text currently in the draft. Since some of the solutions being analyzed in the draft have not been proposed in any other draft, it seems natural for this draft to discuss the privacy implications of those solutions. Alissa has volunteered to take a look at the draft and propose some text to be added. That should help us figure out exactly what additional privacy implications this draft would have, if any, over simply exposing an IP address without any address sharing between different subscribers. Thanks Suresh Joel M. Halpern j...@joelhalpern.com wrote: Joe, I am missing something. There is an observation that the behavior described in this document has privacy implications. Either that statement is true, or it is not. If it is not true, then there is no need to do anything. However, it appears likely the statement is true. If it is true that this document has privacy implications, then the general rule that says that we should document what we know about would seem to come into play. It would seem sensible to include a description of known privacy implications in the document. This seems to be the case even if the absence of any document from anyone, with or without IETF consensus, on the more general issue of looking for privacy issues. Yours, Joel On 11/26/2011 8:40 PM, Joe Touch wrote: On Nov 26, 2011, at 10:21 AM, Francis Dupontfrancis.dup...@fdupont.fr wrote: In your previous mail you wrote: If and when a document describing the privacy considerations requirements has passed IETF review, sure. = to wait this document is published as a RFC to add a privacy consideration section to the nat-reveal I-D is no more reasonable to block all documents related to privacy until it is published... That has not been yet requested. If it were, I would be glad to raise it as a process issue. Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. Right now, that document is an individual submission with no track. = perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. Is hasn't been last called
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Nov 26, 2011, at 8:40 PM, Joel M. Halpern wrote: Joe, I am missing something. There is an observation that the behavior described in this document has privacy implications. Either that statement is true, or it is not. If it is not true, then there is no need to do anything. However, it appears likely the statement is true. If it is true that this document has privacy implications, then the general rule that says that we should document what we know about would seem to come into play. It would seem sensible to include a description of known privacy implications in the document. 1) it is true that this - and many docs in the IETF - have privacy implications 2) it is equally true that there are NO CURRENT GUIDELINES on how to address these issues This is a case of a sudden realization that we all *want* to address privacy. I don't. I don't think it's relevant when all that's being discussed are IP addresses. Nothing about the Internet architecture is intended to keep such addresses private - in fact, quite the opposite. The IAB's current soapbox on this issue is a *start* to that discussion, but hasn't been decided as IETF position yet. This seems to be the case even if the absence of any document from anyone, with or without IETF consensus, on the more general issue of looking for privacy issues. You could claim that there are a few who are significantly concerned about whether this doc should address privacy, but I didn't recall a consensus call on that. A consensus call on the properties of a doc that hasn't been adopted by the WG seems premature (process-wise) anyway. IMO, if the WG adopts this doc then it should have such input, and the decision as to how to address it should be made by the WG. That would start with at least some common agreement on what privacy means and what goals we should have for privacy. HOWEVER - that is the purpose of the IAB's documents, and they (again) are still being developed. Some *WANT* to address these issues in current documents. I claim they are jumping the gun, and need to wait for a common understanding of the goals and terms to be determined first. There is no current IAB or IESG recommendation to hold documents based on the emerging discussion on privacy. Joe On 11/26/2011 8:40 PM, Joe Touch wrote: On Nov 26, 2011, at 10:21 AM, Francis Dupontfrancis.dup...@fdupont.fr wrote: In your previous mail you wrote: If and when a document describing the privacy considerations requirements has passed IETF review, sure. = to wait this document is published as a RFC to add a privacy consideration section to the nat-reveal I-D is no more reasonable to block all documents related to privacy until it is published... That has not been yet requested. If it were, I would be glad to raise it as a process issue. Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. Right now, that document is an individual submission with no track. = perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. Is hasn't been last called either. And its core definitions refer to a induvidual submission. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. = as there is a solution proposed by a third party and I wish to leave the possible announce to him I moved to offline... Based on input from a directorate that is proposed in a doc that is still a draft. This isn't useful. The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. These are security issues and not sufficiently agreed at this time to establish requirements IMO. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Sorry, I obviously meant that Francis does *not* want a waste of time ... etc. jfc ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 27 November 2011 17:32, Joe Touch to...@isi.edu wrote: This draft isn't a treatise on privacy issues, nor should it be. It deals with *addresses* and correlations to hosts, not individuals or personal identities. Somewhat beside the point some personal observations: * When I want to add STD 72 to [[Internet Standard]]s I'm not pleased if that doesn't work, because another user of my ISP managed to get my IPv4 blocked on en:w: for 24 hours. * When I want to watch a perfectly harmless YouTube occupy video I'm not pleased if that doesn't work, because the soundtrack is unfree for German IPs as far as GEMA and Google are concerned. * When I want to visit MS answers / technet / whatever pages I'm not pleased if that that only works if I got one of the o2-DE 89.*.*.* IPs, but fails for the o2-DE 82.*.*.* IPs. * When I visit a geolocation service I'm absolutely horrified if the result is almost exactly correct (= better than the ordinary IP location guesswork) for mobile broadband, because I never agreed on sharing data for my geo position. * When the IETF is starting its discussion about privacy now it is rather late, I got that lesson 30 years ago in an advanced seminar. -Frank (would nevertheless prefer to have fun with IPv6) ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Nov 27, 2011, at 10:14 AM, Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com wrote: ... * When the IETF is starting its discussion about privacy now it is rather late, I agree. That discussion does not center on this document. When that discussion reaches done conclusions that the IETF as a whole endorses, then we need to act. But there is no reason to claim the sky is falling and all docs should stop in their tracks to address THIS. - vs dozens of other overlooked issues, many with legal ramifications too - issue. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: If and when a document describing the privacy considerations requirements has passed IETF review, sure. = to wait this document is published as a RFC to add a privacy consideration section to the nat-reveal I-D is no more reasonable to block all documents related to privacy until it is published... Right now, that document is an individual submission with no track. = perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. = as there is a solution proposed by a third party and I wish to leave the possible announce to him I moved to offline... Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: This claim requires an adequate operationalization of privacy. What exactly does one mean by this? Most of the claims I hear about it, including a number of the windy assertions that there is a fundamental right (whatever that is) to it, seem never to state what exactly it is supposed to mean. = it is in the European Convention on Human Rights as a legal principle so there is at least a basis but I am afraid it won't really help. As a (French) lawyer explained to me one day, a legal text must be as less accurate as possible so it can be applied to more than one particular case so a legal principle... None of this is to say it is impossible to add what you suggest. But it needs something more than to say privacy over and over again: to begin with, how is one supposed to have any clue what features might have privacy implications if one simply doesn't know what privacy means? = it is clearly a job for the IAB and fortunately this seems to have been well understood (cf draft-iab-privacy-considerations) To lean on your analogy a little, security discussions often exhibit the sorts of problems I'm talking about here, too. That is nowise an argument that we don't need the sort of operational definition I'm talking about. On the contrary, many of the nastier security discussions I've ever seen boil down to a disagreement about the boundaries of the term security. = I am sure it is easy to find some examples where a particular point is viewed in favor or against the security according to different people. And we can expect some trade-offs between security and privacy too... Regards francis.dup...@fdupont.fr PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights (see the article 8 about privacy). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Joe, I am missing something. There is an observation that the behavior described in this document has privacy implications. Either that statement is true, or it is not. If it is not true, then there is no need to do anything. However, it appears likely the statement is true. If it is true that this document has privacy implications, then the general rule that says that we should document what we know about would seem to come into play. It would seem sensible to include a description of known privacy implications in the document. This seems to be the case even if the absence of any document from anyone, with or without IETF consensus, on the more general issue of looking for privacy issues. Yours, Joel On 11/26/2011 8:40 PM, Joe Touch wrote: On Nov 26, 2011, at 10:21 AM, Francis Dupontfrancis.dup...@fdupont.fr wrote: In your previous mail you wrote: If and when a document describing the privacy considerations requirements has passed IETF review, sure. = to wait this document is published as a RFC to add a privacy consideration section to the nat-reveal I-D is no more reasonable to block all documents related to privacy until it is published... That has not been yet requested. If it were, I would be glad to raise it as a process issue. Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. Right now, that document is an individual submission with no track. = perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. Is hasn't been last called either. And its core definitions refer to a induvidual submission. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. = as there is a solution proposed by a third party and I wish to leave the possible announce to him I moved to offline... Based on input from a directorate that is proposed in a doc that is still a draft. This isn't useful. The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. These are security issues and not sufficiently agreed at this time to establish requirements IMO. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
I think part of the confusion surrounding this draft arises because of the apparent discrepancy between the stated goal of the draft and the text currently in the draft. Since some of the solutions being analyzed in the draft have not been proposed in any other draft, it seems natural for this draft to discuss the privacy implications of those solutions. Alissa has volunteered to take a look at the draft and propose some text to be added. That should help us figure out exactly what additional privacy implications this draft would have, if any, over simply exposing an IP address without any address sharing between different subscribers. Thanks Suresh Joel M. Halpern j...@joelhalpern.com wrote: Joe, I am missing something. There is an observation that the behavior described in this document has privacy implications. Either that statement is true, or it is not. If it is not true, then there is no need to do anything. However, it appears likely the statement is true. If it is true that this document has privacy implications, then the general rule that says that we should document what we know about would seem to come into play. It would seem sensible to include a description of known privacy implications in the document. This seems to be the case even if the absence of any document from anyone, with or without IETF consensus, on the more general issue of looking for privacy issues. Yours, Joel On 11/26/2011 8:40 PM, Joe Touch wrote: On Nov 26, 2011, at 10:21 AM, Francis Dupontfrancis.dup...@fdupont.fr wrote: In your previous mail you wrote: If and when a document describing the privacy considerations requirements has passed IETF review, sure. = to wait this document is published as a RFC to add a privacy consideration section to the nat-reveal I-D is no more reasonable to block all documents related to privacy until it is published... That has not been yet requested. If it were, I would be glad to raise it as a process issue. Again, stop holding this doc to requirements that gave not been agereed by the IETF as a whole. Right now, that document is an individual submission with no track. = perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. Is hasn't been last called either. And its core definitions refer to a induvidual submission. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. = as there is a solution proposed by a third party and I wish to leave the possible announce to him I moved to offline... Based on input from a directorate that is proposed in a doc that is still a draft. This isn't useful. The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. These are security issues and not sufficiently agreed at this time to establish requirements IMO. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Nov 24, 2011, at 1:22 PM, SM wrote: Hi Brian, At 12:02 24-11-2011, Brian E Carpenter wrote: Only for intellectual property issues. For other liabilities, the insurance is carried by ISOC as Francis says. But I don't see the relevance - if operators or users break legal requirements, that is nothing to do with the IETF anyway. Read the AS IS disclaimer found in older RFCs and now part of the Trust's legal conditions. I think that Francis' point is that the authors are writing a specification Full stop. We are writing a comparison of existing approaches. There is no specification in this doc. which, if implemented, may be illegal to deploy in some jurisdictions. It's premature to draw any conclusion about the merits of the draft at such an early stage. It's premature to put requirements on this document which do not exist throughout the IETF. If there are privacy considerations requirements defined in an RFC, please point to them. Otherwise, this thread is what is truly premature. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: I think that Francis' point is that the authors are writing a specification which, if implemented, may be illegal to deploy in some jurisdictions. = the word may is the right one. If the spec should stay about technical stuff IMHO it is an error to ignore its impact on privacy. In a document produced by a standardization body, this could be even considered as a provocation. But the solution is easy: add a privacy consideration section which explains the technical impact and show the IETF doesn't endorse in any way the not-technical aspects of the implementation of methods described in the spec. It's premature to draw any conclusion about the merits of the draft at such an early stage. = if it is about the not-technical merits this should stay true for the whole life of the document... There has been a few drafts recently on which questions about privacy were raised. If privacy wasn't an issue, the web would be faster ( www.afasterinternet.com ). The discussions in several working groups point to a privacy void, i.e. there isn't any guidance about limiting data exposure when designing a protocol. = IMHO this should change. We solved a similar issue about security, there is no reason the same method won't work for privacy. And we should agree to deny privacy issues is not the right way, shouldn't we? Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On Nov 25, 2011, at 12:46 PM, Francis Dupont wrote: ... = IMHO this should change. We solved a similar issue about security, there is no reason the same method won't work for privacy. And we should agree to deny privacy issues is not the right way, shouldn't we? If and when a document describing the privacy considerations requirements has passed IETF review, sure. Right now, that document is an individual submission with no track. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
At 22:41 15-11-2011, Hannes Tschofenig wrote: I called it stupid to use the IP address for authentication purposes and the presenters made jokes about that statement (in the wrong believe I think they are stupid). Clearly, Joe and Pierre also do not believe that the source IP address can be used for authentication today anymore because that is the main statement of their draft - you have to at least consider the source port as well. I encourage those who believe in these types of authentication mechanisms to come to the OAuth working group meeting tomorrow to hear how other people in the industry do authentication today. Whether it is stupid or not to use IP addresses for authentication purposes, the reality is that there are sites that do it. If OAuth is a viable alternative, the draft could point to it. Even if the authors do not believe in privacy (or and maybe other design properties as well) there may still other people out there who find it important to consider it particularly if it has the potential to void other IETF work. I would like to point out that the author of the draft requested feedback on the ietf-privacy mailing list [1] (I could not find the original message is not in the archive). People are going to ignore privacy considerations if there isn't any feedback or expertise to discuss such issues. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00092.html ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Hi Francis, At 23:09 15-11-2011, Francis Dupont wrote: 3- as far as I know the legal umbrella of the IETF is the Internet Society so I propose suggest if no other way to solve the legal issue to sue the Internet Society at the next meeting in Paris in a French court on the 1 and 2 basis (e.g., to pay a court bailiff to officially see 2...) The legal umbrella of the IETF is the IETF Trust. Regards, -sm ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 2011-11-25 04:57, SM wrote: Hi Francis, At 23:09 15-11-2011, Francis Dupont wrote: 3- as far as I know the legal umbrella of the IETF is the Internet Society so I propose suggest if no other way to solve the legal issue to sue the Internet Society at the next meeting in Paris in a French court on the 1 and 2 basis (e.g., to pay a court bailiff to officially see 2...) The legal umbrella of the IETF is the IETF Trust. Only for intellectual property issues. For other liabilities, the insurance is carried by ISOC as Francis says. But I don't see the relevance - if operators or users break legal requirements, that is nothing to do with the IETF anyway. Read the AS IS disclaimer found in older RFCs and now part of the Trust's legal conditions. Brian ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Hi Brian, At 12:02 24-11-2011, Brian E Carpenter wrote: Only for intellectual property issues. For other liabilities, the insurance is carried by ISOC as Francis says. But I don't see the relevance - if operators or users break legal requirements, that is nothing to do with the IETF anyway. Read the AS IS disclaimer found in older RFCs and now part of the Trust's legal conditions. I think that Francis' point is that the authors are writing a specification which, if implemented, may be illegal to deploy in some jurisdictions. It's premature to draw any conclusion about the merits of the draft at such an early stage. There has been a few drafts recently on which questions about privacy were raised. If privacy wasn't an issue, the web would be faster ( www.afasterinternet.com ). The discussions in several working groups point to a privacy void, i.e. there isn't any guidance about limiting data exposure when designing a protocol. Regards, -sm ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 11/24/11 13:22 , SM wrote: Hi Brian, At 12:02 24-11-2011, Brian E Carpenter wrote: Only for intellectual property issues. For other liabilities, the insurance is carried by ISOC as Francis says. But I don't see the relevance - if operators or users break legal requirements, that is nothing to do with the IETF anyway. Read the AS IS disclaimer found in older RFCs and now part of the Trust's legal conditions. I think that Francis' point is that the authors are writing a specification which, if implemented, may be illegal to deploy in some jurisdictions. It's premature to draw any conclusion about the merits of the draft at such an early stage. Lots of things done on the internet using internet standards no less are potentially or actually illegal somewhere. I can roll my IETF timeline back to the last decade of the 20th century and cruise the various debates, on the presence or lack thereof of encryption, export/import restriction, lawful interception, and more recently both privacy and identity exposure requirements. If I were to come to ay conclusion, it's likely that it would be that there are no axioms. having had the pleasure as an operator of deploying services in jurisdictions with something approaching mutually exclusive requirements I'm going not expect that we can satisfy everyone. There has been a few drafts recently on which questions about privacy were raised. If privacy wasn't an issue, the web would be faster ( www.afasterinternet.com ). The discussions in several working groups point to a privacy void, i.e. there isn't any guidance about limiting data exposure when designing a protocol. Regards, -sm ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Dan Wing If this privacy concern persists, ISP's will be required to deploy CGN for privacy. We do not want that. +1 million. Matter of fact, I've made that exact statement before: http://www.ietf.org/mail-archive/web/int-area/current/msg02963.html Francois (and others) If there is a legitimate (and/or legally required) need for privacy that is not being met by existing IETF protocol implementations, I suggest that you write a draft with a clear set of requirements and/or problem statement, perhaps in cooperation with the privacy directorate so that we can solve it, rather than simply trolling with threats of lawsuits and other vague handwaving about privacy issues for EU citizens. We can't fix what we don't understand. Privacy is a legitimate concern, but I do not want to see us try to bolt on fixes for new privacy requirements to IPv4 life support items without a cohesive strategy regarding what privacy problems we are expected to solve as a whole. No piece-parts solutions. More importantly, I want to see clear consensus that we should indeed fix these issues in IPv4, rather than simply acknowledging that IPv4 is what it is and working to make sure that IPv6 meets the new requirements for privacy as we move towards it. In other words, similar to the last presentation in IntArea yesterday, we need to decide whether the answer is if you want more privacy, move to IPv6, we're not fixing this in IPv4 or not. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: If this privacy concern persists, ISP's will be required to deploy CGN for privacy. We do not want that. = nobody wants that but it is the kind of things which can happen from privacy activists if we continue to provoque them in place to just not pay more attention to them than needed. Francois (and others) = I don't know who you are speaking to? If there is a legitimate (and/or legally required) need for privacy = this is not the point: bt any standard, including technical, the document is very far to address correctly its impact on privacy. So we (me, Francois? and others) simply ask to get this fixed before it is published with a name beginning by draft-ietf-*. Note this is very far from being new, I have warned since the first presentation some meetings ago (March one) than particular care should be required about the sensible privacy aspect in the document. Now you can read it (if you haven't yet) and find how this was translated in the current version, and perhaps you'll understand why this aggravates me a bit. simply trolling with threats of lawsuits = it is not trolling: the problem of the privacy is a legal one and as I am a not lawyer individual the best way to get a legal opinion is from people whom it is the job. Now I expect to get the privacy considerations fixed (oops, there is not yet such a section in the document) before having to show our concern has real basis. vague handwaving about privacy issues for EU citizens. = I have given the pointers to the European Convention on Human Rights in a previous message (20110909 according to grep). Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Dear Hannes, You said: I called it stupid to use the IP address for authentication purposes and the presenters made jokes about that statement (in the wrong believe I think they are stupid). Clearly, Joe and Pierre also do not believe that the source IP address can be used for authentication today anymore because that is the main statement of their draft - you have to at least consider the source port as well. I encourage those who believe in these types of authentication mechanisms to come to the OAuth working group meeting tomorrow to hear how other people in the industry do authentication today. (Btw, I am not the first who had made the observation that IP address for authentication is not such a great idea. Have a look at Steve Bellovin's publication from 1989 with the title Security Problems in the TCP/IP Protocol Suite.) The current text says (http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04): Enabling explicit identification means and adequate security suite is more robust than relying on source IP address or HOST_ID. But tension may appear between strong privacy and usability (see Section 4.2 of [I-D.iab-privacy-workshop]). Do you think this should be elaborated further? Text is more than welcome. Cheers, Med ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Dear Scott, You said: Any persistent identifier that can be used for correlation is risky, because correlation can also be done with higher layer activity, so it facilitates identification (and that facilitates further correlation, and so on, until you have enough information to track someone with ease, even without a host_id). Yes, using persistent identifiers is risky. We tried to capture this in the current text: (see http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04): The volatility of the HOST_ID information is similar to the source IP address: a distinct HOST_ID may be used by the address sharing function when the host reboots or gets a new internal IP address. If the HOST_ID is persistent it may be used to track a host (similar to persistent IP addresses). Note than none of the HOST_ID proposals rely on persistent identifiers; the content of the HOST_ID may be: * An IPv4 address * Some bits of the IPv4 address * IPv6 address * IPv6 prefix * IP address:Port Number. Therefore, the information exposed in the HOST_ID is not worse compared to situations where no address sharing is in the path. For sure, we can add some text to encourage address sharing function to avoid persistent information be leaked in the HOST_ID. Cheers, Med ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Hi Francis, To summarize my position: 1- I believe this (the devices described in the document) infringes my rights as an European citizen (cf European Human Rights) but I am not a lawyer so it has to be tested in a court Sorry but I still don't understand your concern here: * The HOST_ID reveals part or all bits of the internal source IP address. * When no address sharing is in the path, your IP address is revealed to remote servers. Does this mean all ISPs infringe your rights as en European citizen by not altering your source IP address? Do you want ISPs deploy onion routing and the like? Cheers, Med ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
FWIW - I wonder if anyone in the EU so concerned about their privacy has a phone number. Or email address - or worse, their own domain ;-) Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: I have seen the concerns that you and Hannes have raised, and I have requested Alissa to help out the authors with the privacy aspects of this document. I can understand why you are objecting to the document being published as is, but I would like to understand better why you do not want this to be adopted and brought under wg change control so that we can make the necessary changes. = perhaps I was not very clear: my concern is about only a publication under the draft-ietf-* name of the document in its current state, of course I am perfectly fine if the WG takes control, makes the changes I believe are required and then publish it (and I believe Hannes shares this opinion even I prefer he answers for himself). Thanks francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 11/17/2011 5:57 AM, Francis Dupont wrote: In your previous mail you wrote: I have seen the concerns that you and Hannes have raised, and I have requested Alissa to help out the authors with the privacy aspects of this document. I can understand why you are objecting to the document being published as is, but I would like to understand better why you do not want this to be adopted and brought under wg change control so that we can make the necessary changes. = perhaps I was not very clear: my concern is about only a publication under the draft-ietf-* name of the document in its current state, Documents cannot possibly be interpreted as representing the consensus of the IETF until issued as RFCs. If what you say were a real concern, we would never issue draft-ietf-*; documents would always need to go from individual direct to RFC. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
One additional point: I was not able to locate any text requiring IETF documents to include a Privacy Considerations section, or to address privacy issues directly. I saw some recent *drafts* on this issue, but nothing that is agreed to currently impact IETF process. Until those drafts result in such a recommendation or condition, it is premature to enforce them - or any requirement on document structure that they *might eventually* require. Joe On 11/16/2011 7:35 PM, Joe Touch wrote: Hi, all, I find all of this privacy information misplaced as well. We are talking about correlating connections, not PEOPLE. Nothing in this document is related to the identity of an individual. There are other valid recommendations - such as the need to spin IP addresses - that are relevant, but NOT appropriate to discuss in this doc. Yes, the current text on privacy is insufficient, but this document is not intended to resolve all privacy issues. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
-Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Scott Brim Sent: Wednesday, November 16, 2011 11:26 PM To: mohamed.boucad...@orange.com Cc: int-area@ietf.org; JACQUENET Christian OLNC/NAD/TIP Subject: Re: [Int-area] My comments on draft-boucadair-intarea-nat- reveal-analysis-04 from the meeting On Wed, Nov 16, 2011 at 05:34, mohamed.boucad...@orange.com wrote: We seriously considered the privacy comment; this is why we contacted the IETF privacy mailing list hopping to receive feedback (see http://www.ietf.org/mail-archive/web/int-area/current/msg02958.html) but unfortunately only one comment was received (see http://www.ietf.org/mail-archive/web/ietf- privacy/current/msg00092.html). I have been wanting to comment but I am busy with other meetings. You quoted this text from the draft: The HOST_ID does not reveal more privacy information than what the source IP address does in a non-shared address environment (see [I-D.morris-privacy-considerations]). without explicitly stating what is wrong with that text. I would appreciate if you can provide some guidance about the content of the Privacy Section. Thanks. Any persistent identifier that can be used for correlation is risky, None of the proposals create, or use, a persistent identifier. Frankly, I find all this new-found privacy concern to be misplaced, from several perspectives. Today, users disclose their identity (their IP address) whenever they initiate a connection to a server -- their TCP SYN contains their IP address. All of the proposals are doing the same thing -- they are including an IP address (or something with less than 32 bits). To my knowledge, today's ISPs are not under an obligation or requirement to change a subscriber's IPv4 address for purposes of privacy. If my knowledge is inaccurate, and ISP's are under that obligation, those ISPs can also change a subscriber's HOST_ID; this can be accomplished by changing the subscriber's IP address -- like today -- or by changing the algorithm that calculates HOST_ID every NNN hours. As for worries HOST_ID creates a persistent identifier, I realize that adding an identifier is attracting lots of attention and excitement from the IETF. Yet, there are other places that we have even worse correlation but nobody has highlighted: (a) all of the currently-proposed stateless transition mechanisms require creating the same persistency (A+P, Dual-IVI, 4rd, SD-NAT, Deterministic NAT, and probably others), and (b) IPv6's inclusion of MAC address. As for (b), yes, we have an RFC on IPv6 privacy addresses, but that doesn't avoid the problem of correlating to a user and is the _same_ information disclosure as today's publicly-routed IPv4 addresses. It is clear, though, from the confused comments at the microphone and the fact the privacy worry keeps coming up that we will need a presentation at IETF83 in Paris. If this privacy concern persists, ISP's will be required to deploy CGN for privacy. We do not want that. Thus, everyone needs to put their privacy concerns on the table, so that we can address all of the concerns. Statements like this is bad for privacy are not technical; statements like yours which talk about a persistent identifier are technical, and helpful in framing the problems and how HOST_ID does not make the problem any worse than today's publicly-routable IPv4 addresses and tomorrow's publicly- routable IPv6 addresses. because correlation can also be done with higher layer activity, so it facilitates identification (and that facilitates further correlation, and so on, until you have enough information to track someone with ease, even without a host_id). -d Scott ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
-Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Francis Dupont Sent: Wednesday, November 16, 2011 3:09 PM To: Hannes Tschofenig Cc: int-area@ietf.org Subject: Re: [Int-area] My comments on draft-boucadair-intarea-nat- reveal-analysis-04 from the meeting I share your concern about the (or the lack of real) privacy considerations. I know the IETF is still dominated by people from a country where privacy is not a fundamental right so can be considered as a side question. BTW I question if some authors (one lives in the same city than me so should share my concerns?) intimately believe this whole stuff should be simply forbidden to preserve the privacy but they don't follow the right way. To summarize my position: 1- I believe this (the devices described in the document) infringes my rights as an European citizen (cf European Human Rights) but I am not a lawyer so it has to be tested in a court 2- one is not allow to organize public meetings to discuss how to perform clearly illegal actions, in particular from a standardization body 3- as far as I know the legal umbrella of the IETF is the Internet Society so I propose suggest if no other way to solve the legal issue to sue the Internet Society at the next meeting in Paris in a French court on the 1 and 2 basis (e.g., to pay a court bailiff to officially see 2...) Technical objections would be useful. Please make some technical objections. -d Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: Frankly, I find all this new-found privacy concern to be misplaced, = it is not new found, I raised the same issue at least at the last two IETF meetings. And BTW it is not really a technical issue, it is a legal one in many countries (I'd like to believe most at the exception of USA) and as usual with many legal issues we can expect not very rational arguments from the outside... (cf the embedded MAC address for IPv6). To summary I am afraid of the perception of this from the outside, and I argue the IETF *must not* endorse the document (i.e., publish it with a draft-ietf-* name) with the privacy considerations in the current state. Statements like this is bad for privacy are not technical; = unfortunately this is a wish, not an argument, as the real issue is legal and not technical from the beginning as you should get from the issue history. statements like yours which talk about a persistent identifier are technical, and helpful in framing the problems and how HOST_ID does not make the problem any worse than today's publicly-routable IPv4 addresses and tomorrow's publicly- routable IPv6 addresses. = in fact the end of your statement is not fun at all: as far as I know there is a legal lobby in Germany arguing publicly-routable IPv6 addresses is a threat against privacy... I repeat this again: ignoring this kind of problems is *not* the right way to get rid of them. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
In your previous mail you wrote: Technical objections would be useful. Please make some technical objections. = I'll be as friendly as you: don't make this kind of comments in public without looking at the history of the problem first. francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
-Original Message- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Thursday, November 17, 2011 11:26 AM To: Dan Wing Cc: 'Scott Brim'; mohamed.boucad...@orange.com; int-area@ietf.org; 'JACQUENET Christian OLNC/NAD/TIP' Subject: Re: [Int-area] My comments on draft-boucadair-intarea-nat- reveal-analysis-04 from the meeting In your previous mail you wrote: Frankly, I find all this new-found privacy concern to be misplaced, = it is not new found, I raised the same issue at least at the last two IETF meetings. And BTW it is not really a technical issue, it is a legal one in many countries (I'd like to believe most at the exception of USA) and as usual with many legal issues we can expect not very rational arguments from the outside... (cf the embedded MAC address for IPv6). To summary I am afraid of the perception of this from the outside, and I argue the IETF *must not* endorse the document (i.e., publish it with a draft-ietf-* name) with the privacy considerations in the current state. Statements like this is bad for privacy are not technical; = unfortunately this is a wish, not an argument, as the real issue is legal and not technical from the beginning as you should get from the issue history. statements like yours which talk about a persistent identifier are technical, and helpful in framing the problems and how HOST_ID does not make the problem any worse than today's publicly-routable IPv4 addresses and tomorrow's publicly- routable IPv6 addresses. = in fact the end of your statement is not fun at all: as far as I know there is a legal lobby in Germany arguing publicly-routable IPv6 addresses is a threat against privacy... I repeat this again: ignoring this kind of problems is *not* the right way to get rid of them. Then please make a technical argument. -d Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
From: Francis Dupont francis.dup...@fdupont.fr there is a legal lobby in Germany arguing publicly-routable IPv6 addresses is a threat against privacy... This is interesting. Can you give some more details? And exactly do they mean by 'publicly-routable IPv6 addresses' - I would assume they aren't against 'IPv6 addresses which are routable in the core', which is what I would assume that means - so they must not like assigned such things to individual subscribers, or something? Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
On 17 November 2011 04:59, Noel Chiappa j...@mercury.lcs.mit.edu wrote: there is a legal lobby in Germany arguing publicly-routable IPv6 addresses is a threat against privacy... This is interesting. Can you give some more details? http://www.heise.de/newsticker/meldung/Datenschuetzer-geben-Empfehlungen-fuer-IPv6-Einsatz-1372096.html Summary, German privacy commissioners recommend to use the dynamic IPv4 concept also for IPv6. It's an ongoing debate, not a final verdict. But if IPs are correctly identified as sensitive data it has legal (in Germany) consequences for, e.g., logging of IPs. -Frank (back to lurking) ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
