Adding lisp@xxxxxxxx to cc list. How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated? I have made suggestions before that such a working group should be in the ops area. Some examples include and are not limited to v6ops, dnsop, and mboned. Cheers, Dino > On Oct 4, 2017, at 12:45 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > > Hiya, > > TL;DR - I am now even more convinced that this ought not > go ahead. (Sorry;-) > > On 04/10/17 19:48, Alexander Clemm wrote: >> There were a couple of things raised in the overall thread that I >> just wanted to quickly respond to: >> >> Clearly privacy is an important issue and concern. The current >> charter proposal includes a requirement for a detailed analysis of >> this aspect. If this aspect needs to be expanded, sure, let's do >> this. > > TBH, I don't think that'd help, for me at least. I don't > see any way in which such permanent strings representing > identity can be defined to be usable as claimed and not > be perniciously privacy invasive. So some promises to > ponder the problem in charter text wouldn't do it for > me. (And tbh, I've seen that can kicked down that road > before, so I'm skeptical of such promises in general.) > >> Everyone seems to be jumping up and down regarding the use of the >> term of "identity" as if a foregone conclusion that this is a synonym >> for "privacy invasion". However: - "Identity" does not imply >> "personal identity". Really, this is an identifier scheme for >> endpoints. > > Sorry, what I assume is the relevant draft [1] says the "identity" > (denoted "IDy") is a "Unique and Permanent Identity" and that > "Networks may treat traffic differently depending on the IDy of > source or destination" and also seems to envisage a large logical > database of everyone's IDy's: "Identity also allows to have metadata > associated it to be applied, regardless of which IDf is used to > refer it." (Where IDf is the identifier that'll later be mapped > to a locator via, I assume, HIP or LISP or similar.) > > I think it's entirely correct to jump up and down about the > privacy consequences of the above. (Not to mention the potential > censorship and discriminatory aspects.) > > [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01 > >> Perhaps even "identity" is a misnomer. > > Well, it was presumably your choice (where your == some set of > the proponents). If that's a mistake, then it seems a fairly > fatal one - to get the name wrong for an effort all about mapping > names to identifiers;-) > >> If you will, >> identity as conceived in the context of IDEAS is a second level of >> identifier that does not have to be exposed over the data plane - >> Because of this, it may result in greater privacy than existing >> schemes, not less. > > I see that argument in [1] but I'm not buying it tbh. To get > that level of protection from such an indirection, one would > have to have something like Tor hidden services and perhaps > one would have to *not* standardise the mapping from human > meaningful identifiers to those used as IDf, and esp. not the > reverse mapping. Defining that reverse mapping cannot but be > privacy invasive afaics. (There could maybe be ways to define > how an already hashed human meaningful identifier could then > be further hashed to become an IDy but I don't really see the > point of that at all, other than to just standardise something > for the fun of the process.) > >> It enables you, for example, to obfuscate >> endpoints to outside observers as you wouldn't need to use personal >> unique long-lived identifiers, quite the contrary. - There is also a >> security dimension here. If I am victim of a phishing attack because >> my network information (like today) is exposed to botnets, > > (Nit: that says nothing about being a victim of, only of being > a target of, an attempted attack. Speaking of victims also > tends not to lead to more objective analysis, so I think it's > better to not go there unless it's relevant, which I don't > think is the case here, because...) > > I don't understand what network information you mean. If you > mean email addresses, and are proposing that the email ecosystem > change to use some IDf or LOC values, that doesn't seem at all > realistic to me. If you don't mean email addresses then I don't > see how any lower layer change will affect attempted phishes. > The routing area is probably also the entirely wrong venue for > any real anti-phishing effort. > > That really wasn't a good example;-) > >> phishers >> etc who can hide from me (but not I from them) and remain anonymous >> or impersonate legitimate users, I do consider this a very serious >> threat also to my privacy. How can IETF counteract such threats? I >> think that IDEAS, if done right, can provide a contribution here. > > I don't see that at all. Unless I'm mistaken that seems like > wishful thinking to me. > >> >> One aspect that has been missing from the discussion is the question >> whether there is a distinction between the network provider who >> provides GRIDS services and an outside attacker / observer. I think >> this distinction is important. The way I see it, if done right >> (sure, big "if", and requiring detailed analysis), IDEAS as I would >> envision it can contribute greatly to provide greater security and >> privacy from outside attackers. At the same time, as it is currently >> envisioned, there clearly is a trust relationship between an entity >> and the provider of "its" GRIDS services. The mapping database will >> have information about locator-identifier and identifier-identifier >> mappings, so GRIDS will know which identifiers its endpoints are >> using. Clearly, if this trust is abused because the provider cannot >> be trusted, if you are concerned that it sells your endpoint’s >> information to the mob or a suppressive government, there is an >> issue. However, when concerned about this scenario, it seems to me >> one would have equal reason to e.g. not trust your mobile service >> provider either, who can track you, knows your location, and has your >> customer data. > > ISTM that introducing that GRIDS thing makes matters worse and not > better, because, as you yourself say, it is clear that whoever has > access to the GRIDS information would be better able to track people > compared to now. > > I would prefer to see fewer long lived identifiers in networking > and not more, and this proposal introduces more long lived identifiers > (erroneously calling those identities). > > Regardless of what one thinks of them, given that things like > HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit > adding this extra layer of indirection with a privacy invasive > "Unique and Permanent" identifier which seems to be the only > non-overlapping part of this work - in fact I only see downsides. > > Cheers, > S. > > >> >> --- Alex >> >> >>> -----Original Message----- From: Ideas >>> [mailto:ideas-bounces@xxxxxxxx] On Behalf Of >>> stephen.farrell@xxxxxxxxx Sent: Wednesday, October 04, 2017 9:35 >>> AM To: tom@xxxxxxxxxxxxxxx Cc: ideas@xxxxxxxx; >>> phill@xxxxxxxxxxxxxxx; ietf@xxxxxxxx Subject: Re: [Ideas] WG >>> Review: IDentity Enabled Networks (ideas) >>> >>> >>> >>> On Wednesday, 4 October 2017, Tom Herbert wrote: >>>> On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker >>>> <phill@xxxxxxxxxxxxxxx> wrote: >>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell >>>>> <stephen.farrell@xxxxxxxxx> wrote: >>>>>> >>>>>> >>>>>> As currently described, I oppose creation of this working >>>>>> group on the basis that it enables and seemingly encourages >>>>>> embedding identifiers for humans as addresses. Doing so would >>>>>> have significant privacy downsides, would enable new methods >>>>>> for censorship and discrimination, and could be very hard to >>>>>> mitigate should one wish to help protect people's privacy, as >>>>>> I think is current IETF policy. >>>>>> >>>>>> If the work precluded the use of any identifiers that >>>>>> strongly map to humans then I'd be ok with it being done as >>>>>> it'd then only be a waste of resources. But I don't know how >>>>>> that could be enforced so I think it'd be better to just not >>>>>> do this work at all. >>>>>> >>>>>> S. >>>>> >>>>> >>>>> +1 >>>>> >>>>> I know how to restrict the work to 'meaningless' identifiers, >>>>> require that the identifiers be the output of a cryptographic >>>>> algorithm. >>>>> >>>>> Now strictly speaking, this only limits scope to identifiers >>>>> that are indexical as opposed to rendering them meaningless but >>>>> I think that was the sense of it. >>>>> >>>>> >>>>> Nöth proposed a trichotemy of identifiers as follows >>>>> >>>>> * Identity, the signifier is the signified (e.g. data: URI) >>>>> >>>>> * Indexical, the signifier is related to the signified by a >>>>> systematic relationship, (e.g. ni URIs, SHA256Data), PGP >>>>> fingerprints etc.) >>>>> >>>>> * Names, the signifier is the related to the signified by a >>>>> purely conventional relationship, (e.g. example.com to its >>>>> owner) >>>>> >>>>> >>>>> There is a big difference between attempting to manage >>>>> indexical signifiers and names. Especially when the people >>>>> trying to do so refuse to read any of the literature on >>>>> semiotics. >>>>> >>>>> Names are problematic because the only way that a conventional >>>>> relationship can be implemented is through some sort of >>>>> registration infrastructure and we already have one of those >>>>> and the industry that manages it has a marketcap in the tens of >>>>> billions. >>>>> >>>>> Identifiers do lead to tractable solutions. But, this proposal >>>>> looks a bit unfocused for IRTF consideration, an IETF WG? >>>>> Really? >>>>> >>>> Identifiers are equivalent to addresses in that they indicate a >>>> node in the network for the purposes of end to end >>>> communications. The only difference between identifiers and >>>> addresses is that identifiers are not topological. Virtual >>>> addresses in network virtualization are also identifiers. So the >>>> security properties are the same when considering privacy. For >>>> instance, if applications use temporary addresses for privacy, it >>>> would have equivalent properties using temporary identifiers. In >>>> fact from the application POV this would be transparent. It could >>>> get a pool of apparently random addresses to choose from as >>>> source of communication, it shouldn't know or even care if the >>>> addresses are identifiers. >>>> >>>> Identity is a completely separate concept from identifiers. Is >>>> not required in any of the identifier/locator protocols and AFAIK >>>> none of them even mention the term. There is no association of an >>>> identity of user behind and identifier any more than there is an >>>> association of identity behind IP address. The fact that the >>>> words "identifier" and "identity" share a common prefix is an >>>> unfortunate happenstance :-). >>> >>> >>> Yes. But doesn't that mean either the name of this effort is wildly >>> misleading or else the effort is hugely problematic from a privacy >>> POV? Either way, istm this ought not proceed. >>> >>> S. >>> >>>> >>>> Tom >>>> >>> _______________________________________________ Ideas mailing list >>> Ideas@xxxxxxxx https://www.ietf.org/mailman/listinfo/ideas > > _______________________________________________ > Ideas mailing list > Ideas@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ideas