Hi Dino, On 04/10/17 21:35, Dino Farinacci wrote: > 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. If there's deployment of things like LISP and HIP and folks are interested in discussing/documenting what they've been doing in the ops area then that seems quite reasonable sure. S. > > 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 > >
Attachment:
signature.asc
Description: OpenPGP digital signature