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