Subject: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

From: "Stastny Richard" <[email-masked]>
Date: Sat, 19 Jun 2004 09:15:39 -0400

Jeff Williams writes:
>And this to a very great degree is what is wrong with the standards
>track with ENUM.  Both opt-in and Opt-out should be incorporated.

They did. The ENUM protocol as defined in IETF can be implemented
in both ways, athough NOT in the same tree, because the both options
are mutually exclusive.

Let me explain: Opt-in means that at the beginning nobody is in and the
end-user decides if he wants to be in to get this service. This is the case
with User ENUM, which is an add-on service. The underlying service
is his phone service and this phone service is working regadless if
he is in ENUM or not (with the exception of ENUM-enable numbers,
which are operating only if you are in User ENUM, but nobody is
forced to use these numbers)

The end-user has the additional choice how much information he
discloses: the minimum requirement is the number itself and the
operator, if he puts in e.g. sip:+43xxx at provider.net. Additional
information between caller and callee may be exchanges via
negotiation between servers (as in SIP) or Personal User Agents
as proposed in UCI. The end-user may also decide on his discretion
to put in more information as he likes, especially a company.

Opt-out would mean that everybody is in and the end-user decides not
to be in. If a provider decides to implement the basic communication service
based on ENUM, he MUST put all users using this service in ENUM.

Using ENUM for a service is currently also opt-in, but for the provider as
a whole with all of his numbers. There is no opt-out for the individual
end-user.  This is called Infrastructure ENUM. It uses ENUM technology,
but in separate tree. It is opt-in currently because there is still the PSTN around
to reach providers not in Infrastructure ENUM by default. If the PSTN ceases 
to exists at some point of time, another default method need to be defined if
E.164 numbering is still around. This may be ENUM or maybe not.

Up to this point of time, different trees may be used by different groups
of service providers (confederation), this is already happening. A service 
provider may even participate in different trees at the same time.

 These trees may either be trees only accessible by participants of the 
confederation (either in extranets or with access control), but not
on the public Internet, or if accessible by the public, the information
is either not accessible, encrypted or useless for the normal end-user.

There is also a difference between the information contained in
the trees. 

In User ENUM the information points to end-points,
giving one ore more URIs where the end-user has his services.
Different NAPTRs may point to different service providers.
The domain name holder is the end-user.

In Infrastructure ENUM the entry points in principle to
the destination network providing the service for this number.
The domain name holder is the service provider.

All this together precludes User ENUM and Infrastructure
ENUM to be in the same tree (even the delegation structure
may be differnent).

Of course User ENUM and Infrastructure ENUM may co-exist,
any user listed in one or more Infrastructure trees may also
request an entry in User ENUM. The provider may also offer
to the calling customer a service in such a way that first User 
ENUM queried and then Infrastructure ENUM. This is already
implemented in some SIP servers and works. (Note: why should
the provider do this? Because the user may do this by himself also.
It is kinda carrier selection ;-)

ETSI is currently drafting a TS 102 055 on Infrastructure ENUM
explaining all these issues.

BTW: there is one complication emerging at the moment:
Confederations also want Infrastructure ENUM to be used
for routing of transit calls, e.g. an provider is publishing number
ranges in a confederation tree he is serving on the PSTN with his
gateways. This is in principle feasable, but will cause serious problems
in the future, especially if two confederations decide to merge there
trees. If one numbers are entered by providers which are assigned
to them, no conflicts could arise if trees are merged.

If numbers are entered by providers not assigned to them, this
will cause policy problems and conflicts. These conflicts cannot
be resolved in ENUM, because it is not designed for it. Other
protocols like TRIP or OSP should be used for this.

Richard:
To Jeff: You know what my problem with all privacy advocates is?

They are trespassing my privacy by trying to limit my freedom of decision,
including my human right to make idiotic decisions ;-)

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Sat, 19 Jun 2004 22:57:12 -0400

Stastny and all,

> in both ways, athough NOT in the same tree, because the both options

  You again misunderstood what I said. That may be my fault however.
So I will try to be more precise.  The user should be able to have either
opt-in or opt-out regardless of which tree.  And that in the current
protocol is not provided for, and easily could be.

> with User ENUM, which is an add-on service.

  Yes I already knew this, so this exercise is not necessary...

> The underlying service

  Again yes I also already knew this as well.  And here is one of the
problem areas in the current standards track protocol.  If you do not
choose as a User ENUM to use these numbers you effectively do
not have ENUM capability which is a trap that is by design, and bad
design at that, to pressure any user to use these numbers and therefore
expose themselves to privacy violations or intrusion of various sorts
unnecessarily.

> operator, if he puts in e.g. sip:+43xxx at provider.net.

  Yes and the minimum requirement is another area where the user
is exposed to privacy intrusions as he/she need need not have to
have the number disclosed or even listed or viewable in DNS
records, but  still available to law enforcement agencies upon
notification of the user in advance.

> Additional

This I also already knew.  And the proposed UCI is a bit too loosely
worded as to whom decides what the user can direct his/her
"personal agent" to disclose and whether any restrictions are
at the users discretion.  Hence exposing the user to potential
further damage should said personal agent decide without prior
consent, such disclosures...

> based on ENUM, he MUST put all users using this service in ENUM

  Yes, and this I also already knew and again exposes unnecessarily the
user to potential privacy intrusions of obvious and already discussed
various sorts.

> E.164 numbering is still around. This may be ENUM or maybe not.

  Yes again exactly right, and I already knew as well as demonstrates that
anti-privacy bigots do not wish of users to have opt-out for reasons that
are of a political and philosophical nature which may or may not be shared
by some of many users and also not in concert with EU's for instance,
laws.

> The domain name holder is the end-user.

  Right, and as the user does not own his/her domain name currently
he/she is exposed to others making many privacy and security decisions
for him/her depending on the service agreement the provider has or
may change from time to time.

> The domain name holder is the service provider.

  Right if and when the Domain Name holder is also the service
provider which would not be the case in most instances...

> explaining all these issues.

  Yes I have seen early parts of this draft..

> to them, no conflicts could arise if trees are merged.

  Agreed that there could be some problems in the instances where
said confederations are merged for some reason or another such
as a business merger or buyout.  But again they can be overcome
without intruding either previous confederations users discretion
regarding any privacy exposures.

> including my human right to make idiotic decisions ;-)

  Hummm?  Well I honestly don't see how such a situation is relevant
or even possible.  Freedom to choose is also a part of protecting
anyone's privacy.  Idiotic decisions by someone that does so for
others, knowingly of that or those persons is a responsibility of
great gravity sometimes.  For oneself, and only effecting oneself,
idiotic decisions are of course expectable however damaging
to oneself only, they may be...

  Ask yourself, do you NEED access to my ENUM number?
Does any network operator NEED unrestricted access to my
ENUM number?  Would access of any sort or at any level
to any number other individuals, regardless of supposed status
or position not have the increasing potential of the domain name
holders ENUM number not expose him/her to potential if not
eventual definite abuses of various sorts, some being of a
life threatening nature?  I believe the answer to this question
to definitely be, YES.  And THAT is not expectable and
preventable if the current ENUM standards track/protocol
incorporates at least most of the exposures now known and
have been known for some time...

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 21 Jun 2004 02:38:40 -0400

> protocol is not provided for, and easily could be.

That's nonsense. I can't opt out of the telco switching database, nor
should I be able to.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Mike Hammer <[email-masked]>
Date: Mon, 21 Jun 2004 19:45:31 -0400

Jeff,
Just out of curiosity, how did the opt-in versus opt-out issue play out 
with other domain names in the DNS?  Is it possible to have a domain name 
not in DNS that is useful?

Also, are you asserting that having an entry in User ENUM and privacy are 
mutually exclusive?  (That it is impossible by the content of the record in 
ENUM to provide privacy?)

An E.164 number could be viewed as a public resource that is assigned to 
you to aid in establishing connections through the collective public 
telephone network.  It would not make sense to allow users to take E.164 
numbers out of circulation and thus cause everyone else's number to have to 
increase in length (any more than necessary) as a result.  I'm trying to 
understand the model whereby you move the number to the IP domain, but then 
don't put it into ENUM to enable calls to be routed to it.  Perhaps you 
could clarify what it means to opt-out or not opt-in?

Not for or against anything just yet, just trying to understand exactly 
what data you consider private versus public.

Mike
At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote:
Stastny and all,

---

From: Jeff Williams <[email-masked]>
Date: Mon, 21 Jun 2004 20:02:45 -0400

Clive and all,

> That's nonsense. I can't opt out of the telco switching database, nor

  No what I said above was not nonsense.  But your response is.  I didn't
suggest to opt-out of the telco switching database.  I did suggest that that
data should not be viewable or accessible in either tree.  Big difference! >:)

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Tue, 22 Jun 2004 02:06:57 -0400

Mike and all,

  I am sure I have stated this before on behalf of our members.  However
I will not post here how such methods can be deployed as to violating
privacy through various nefarious technical means can be achieved as
to do so would only serve to potentially provide those that would do so
to have gotten a number of ideas by which using said methods could be
added to their own and therefore used for nefarious purposes unnecessarily.
I am guessing that you Mike know or know of some of the methods to
which I am indirectly and on purpose referring to.

  The number assigned if publicly accessible or even viewable is in and
of itself a privacy intrusion that should not be allowed.  Same is true
for operators of ENUM activated networks such a Telco's having
same of similar access to said assigned numbers.  In addition if
a whois lookup would by default display a ENUM number assigned
to that domain Name or Names in the case of a bulk whois look-up
than those persons privacy has been compromised unnecessarily and
could damage them in a number of ways such as stalking, identity
theft of various sorts.

Regards,

---

From: Mike Hammer <[email-masked]>
Date: Tue, 22 Jun 2004 18:31:30 -0400

Jeff,
It is well known in security circles that "security through obscurity" is 
no security at all.  Best not to design technical solutions around 
mechanisms that have not been well inspected by respected experts.

The number in and of itself is not private and can not be made so, or the 
ability of the public telephone network can not work.  (You can not by 
legal fiat force all the world's telephone operators to remove partial or 
full telephone numbers from their databases.  It is not possible to doing 
routing correctly without them.  I point out the parallels between ENUM and 
the LNP databases to show the folly and error of such positions.

There are also nefarious purposes for taking E.164 number assignments and 
then not making use of them in the PSTN.  It is not in the public interest 
to allow that to occur, and being in the IP-domain does not make a valid 
basis for an exception.

You are on much safer ground when you argue that the linkage of other 
information, which could be deemed privacy-related (names, employer, postal 
addresses, geographic location, etc.) within databases is subject to the 
privacy laws of various countries.

I would argue that for any E.164 number in the form of a domain name that 
is found within the DNS, if the resulting records point simply to 
information of a service or a service provider address that does not 
provide more information specific to an individual subscriber, then no 
privacy violation has occurred.  Any messages sent to that address, be they 
http, email, im, sip, h323, or whatever can then be handled on their own 
terms.  Routing happens.

I understand that vagueness provides employment for many lawyers, but this 
is a case where ambiguity undermines a key infrastructure and the need for 
precision is paramount.

Mike
At 08:09 PM 6/21/2004 -0700, Jeff Williams wrote:
Mike and all,

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Thu, 24 Jun 2004 12:41:58 -0400

Mike and all,

Mike Hammer wrote:

> no security at all.

  Well I disagree with this statement entirely.  If it were not for using
obscurity some many years ago now, I would not be alive today.
Using good "Obscurity" techniques has always been a good form of
security, both man made, and in nature.

>  Best not to design technical solutions around

  Understood here of course.  As one of those respected experts
in some circles, I can of course appritiate this comment/remark.

> ability of the public telephone network can not work.

  Why not?  Just because someone says it cannot be made private
to a degree.  But that I mean, it can be "Unlisted" for "Public"
consumption or in whois lookup's ect...

>  (You can not by
> full telephone numbers from their databases.

  I am not suggesting that telephone operators do so.  I AM asking
and even demanding as the spokesman for our members, that those
numbers not be publicly listed or avalible for viewing even by any
operator.  For instance,  you cannot view or even get my home phone
number right now even if you called information for Frisco Texas, as
it is not listed.  Try to do so and see if you can.  Than post it here,
and I will tell you if it is my home phone number or not.  Good luck!

  I also have 3 different cell phone numbers which presently are also
not listed, nor I would bet can you obtain 2 of them via any directory.
The one which is my main contact phone number is listed in my sig file
below, and is sometimes forwarded to my office phone, home phone,
and rarely but sometimes forwareded to my China based cell phone
number.  I would bet you would not be able to find the remaining two
cell phone numbers listed, but NOT publicly provided access.  Care
to place a wager?  >:)

> It is not possible to doing

  Nonsense.  What I believe you are saying is NOT what I am suggesting
( see above comments/remarks and again previous remarks/comments
in this regard ).  So I think we have a disconnect, if you will pardon the
pun. >:)  What I am, and have been saying/suggesting in several ways,
is that "User ENUM" numbers need not be publicly viewable in
Whois or any other lookup facility data by anyone.  And yet can still be
used for other database functions such as archiving, ect...

> privacy laws of various countries.

  "User ENUM" numbers can be used, as I have said repeatedly to track
location of the owner or user of that number.  Hence further, postal address
can also be extrapolated when starting with a "User ENUM" number, allowing
for stalking, and other privacy as well as security related concerns if said
"User ENUM" number is not sufficiently "Obscured" ( your term ) from
public access.

> privacy violation has occurred.

  I would respectfully disagree with this argument/assertion.  Again based
on what I have already outlined several times now. ( also see in brief, above ).

>  Any messages sent to that address, be they

  Routing can still happen uninterrupted even if the "User ENUM" number
is "Not publicly listed" but still available for routing purposes.

> is a case where ambiguity undermines a key infrastructure and the need for

  Agreed.  I have tried to be precise, yet brief and to the relevant points
regarding privacy, accuracy, and functionality.  I believe I have done so.
And done so again here, without being overly technically distinct.

Regards,