ENUM: Bad For Privacy, or Very Bad For Privacy?
Date: Monday February 24 2003, @12:03PM
Topic: Privacy

There's a lot happening with ENUM fairly quickly, and it's hard to keep track of half of it. Alas, one thing about ENUM seems pretty clear: as currently specified, ENUM's intersection with the DNS creates a major privacy problem for the average person. ENUM partisans tend to admit this in person, often even before being cornered. The trouble is, they keep pressing on trying to write standards without dealing with the problem. (All the more reason why WHOIS privacy issues matter so much!) Here -- I think -- is not just one case in point, but two, both of which dropped into my mailbox today: Internet-drafts for " Registration for enumservices voice and video" and for "IFAX service of ENUM". The two documents also provide an interesting stylistic contrast in methods of flagging the issue.

Let's start with "Registration for enumservices voice and video." The Abstract says

This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange.

Specifically, the "enumservices" registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'.

For each service we're told
"Security Considerations:
There are no specific security issues with this 'enumservice'.
However, the general considerations of section 6 apply.
What, one wonders, are those "general considerations"? Well, it turns out there are a lot of them.
6. Security Considerations

DNS, as used by ENUM, is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a Telephone Directory, it does open the data subject to having "their" information collected automatically without any indication that this has been done or by whom.

Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they are sent increases when they post to the mailing list; publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS" for example.

Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus providing a "sacrificial" phone number in any publication is not possible.

Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give their explicit informed consent to data being published in ENUM.

In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.

However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that their consent for its publication is explicitly confirmed at regular intervals.

When placing a voice or video call via the PSTN or sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that the end user be asked to confirm sending the message, and that the destination number be presented to them. It is the originating user's choice on whether or not to place a call to this destination number, but they SHOULD be shown the destination number so that they can make this decision

Where voice or video terminals are configured to accept incoming calls, there SHOULD be an indication presented to the user that an incoming call is being offered. Particularly with some video systems, the terminal may be configured to "auto-accept" the call. In this case there MUST be an obvious indication presented to the calling user that this has been done.

Systems configured to auto-accept audio/video calls that are sent to a number published in a global public directory may be used by unexpected individuals to check for the presence or otherwise of people for with a view to stealing property or other unwelcome acts. Whilst "security through obscurity" may have seemed acceptable when the access address was known to only a few, publication within ENUM removes the obscurity, so leaving (for example) a "WebCam" switched on after such publication is even less wise than in other situations.

In addition to the specific security considerations given above, all security considerations given in RFC2916bis apply.

Contrast all this with the far more cursory treatment in "IFAX service of ENUM":
Security Consideration
The Security Considerations section of [RFC2305] and [RFC2532] applies to this document. In addition, note that DNS records are public. Therefore the mapping between a telephone number and a specific email address is public.
Even the short form ought to make you sit up and take notice.

This discussion has been archived. No new comments can be posted.
ENUM: Bad For Privacy, or Very Bad For Privacy? | Log in/Create an Account | Top | 2 comments | Search Discussion
Click this button to post a comment to this story
The options below will change how the comments display
Check box to change your default comment view
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
by Anonymous on Monday February 24 2003, @03:22PM (#11235)
I notice the following domains are taken: enumservice.com, enumservices.com.
[ Reply to This | Parent ]
by RFassett on Tuesday February 25 2003, @08:26AM (#11238)
User #3226 Info | http://www.enum.info
I thought I saw the other day a news highlight that that this (link below) is going to become an effort at the federal level by this summer...people will be able to opt-in to this "registry" at no charge:

http://www.puc.state.tx.us/ocp/telephone/donotcall .cfm

does not the solve the e-mail spam or potential sms abuse, but looks to address the PSTN portion (in the US), I think, relative to ENUM implementation?
[ Reply to This | Parent ]

This article comes from ICANNWatch

The URL for this story is: