Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 2 Jan 2007 11:14:24 +0000

Livingood, Jason said:
> Attached is the new -04 draft, which was just submitted to the editor.
[...]

> 5. Security and Privacy Considerations 
>     
>    Since Infrastructure ENUM is also implemented on the public Internet, 
>    the same security considerations apply as noted in RFC 3761. 
>      
>    In addition, since there is no opt-in for end-users, personally-
>    identifiable information (PII) must not be disclosed for any end-
>    user.  
>     
>    Thus, the information provided in the NAPTR records must not disclose 
>    any PII about the end-user such as a name in user-info. This can be 
>    achieved, for example, by entering the information in the format 
>    sip:<e164_phone_number>@provider.example.net,  
>    mailto:<e164_phone_number>@provider.example.net or sip:<opaque 
>    string>@provider.example.net. 

The UK's Office of the Information Commissioner have stated that the
identity of the provider used by a user *is* PII in this context.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: <[email-masked]>
Date: Tue, 2 Jan 2007 03:37:04 -0800

Is the legal opinion an assertion that:-

The fact of association of a provider with a consumer is 
PII, when its related to that users phone number 
registration?

Given the pretexting scandal, which showed up how limited 
privacy is in the US space, would we be now saying that even 
attempting to determine the association (search the DNS, or 
resolve a ENUM address) would be presumed to be an attempted 
act against that privacy interest?

This is a bit similar to another UK example. Given a URL, 
modifying it and resolving it can then be a criminal act - 
being an unlawful search that abuses the IT system in 
question, in an "unauthorized manner".

The value here is that folks establishing an expectation of 
privacy have concrete means of enforcing it. Its more than a 
vague idealistic idea, as in the traditional Internet where 
privacy was useful mostly for marketing.

----- Original Message -----
From: "Clive D.W. Feather" <[email-masked]>
To: "Livingood, Jason" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 02, 2007 3:14 AM
Subject: Re: [Enum] NITS review of 
draft-ietf-enum-infrastructure-03

---

From: lconroy <[email-masked]>
Date: Tue, 2 Jan 2007 11:39:32 +0000

Hi folks,
  I am unaware of a formal written opinion from the Information
Commissioner on this matter.
Until there is such a formal opinion and clarification on permitted
data, IMHO this draft is fine. Otherwise we are chasing phantoms.

If any NRA or equivalent data protection authority refused to permit
a necessary part of SIP URLs to be published, then doing so would
make VoIP in general rather hard. An originating system has to be able
to "find" the destination SIP provider or it isn't going to work. I hear
rumours, but I can't believe anyone intends to block VoIP in this way.

I'm waiting for an official, tested, opinion before making any other  
comment.

all the best,
   Lawrence

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 4 Jan 2007 16:42:40 +0000

> Commissioner on this matter.

I'm not sure if it's formal and written, but I know that the OIC has
expressed this opinion. I'll see if I can track it down.

> data, IMHO this draft is fine. Otherwise we are chasing phantoms.

On the contrary, the same issue is already causing problems within NICC
(the UK telecoms standards body).

> rumours, but I can't believe anyone intends to block VoIP in this way.

There's a difference between User (opt-in) and Infrastructure (everyone is
included) Enum in this context. I'm referring to Infrastructure Enum only.

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 5 Jan 2007 12:37:19 +0100

> included) Enum in this context. I'm referring to Infrastructure Enum only.

I'm not sure whether the suggested legal problems stem from EU law or
national .uk one. In any case, you might be interested to hear that
the Austrian NRA (RTR GmbH) happily signed a contract with us
designating us to run an infrastructure ENUM trial in the *public* DNS.

Whether that's just because we Austrians tend to be creative in the
interpretation of EU regulations or whether there is really no problem
there, I can't tell.

But it's a fact that we run an officially sanctioned I-ENUM trial
here in an EU member state.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 5 Jan 2007 13:29:16 +0100

> here in an EU member state.

Two more points on this:

* If the mapping "Telephone number" -> "provider" is one you're
  worried about being public, then Austria already has that 
  problem with all mobile numbers:

  The block allocations to carriers are simple, published, and 
  well known to the public. (e.g. +43 664 -> Mobilkom, +43 676
  -> T-Mobile, ...)

  If someone ported a number from one carrier to another
  then an announcement indicating the new carrier is played 
  every time such a number is called.
  
  That announcement was necessary as tariffs depend on the
  destination network, thus with MNP, consumers could
  no longer derive the tariff by simply looking at the
  number.

  The upshot is: it's trivial to find out which mobile
  carrier services a certain number.

* Maybe we need to stress one point from 
  draft-ietf-enum-infrastructure-enum-reqs-03 which
  is not mentioned in draft-ietf-enum-infrastructure-04:

>From "2.2.  Background"

| There is also no guarantee that the originating service provider
| querying infrastructure ENUM is able to access the ingress network
| element of the destination provider's network.  Additional peering and
| accounting agreements requiring authentication may be necessary.

  In other words: the information found in the public I-ENUM
  tree (e.g. [email-masked]) does not enable
  anybody and his dog (and Nigerian spammers) to call that number
  directly from his robo-call Asterisk box using SIP.

  If you're no carrier with an established peering relationship
  with "example.net", then you gain next to nothing by knowing
  the mapping +43123456789 -> [email-masked].

/ol

---

From: Jay Daley <[email-masked]>
Date: Tue, 16 Jan 2007 23:25:16 +0000

Clive

> expressed this opinion. I'll see if I can track it down.

No need to track it down as I was in the room when the opinion was given. 
It was clearly stated as an opinion from OfCom (the UK telecoms regulator) 
that OIC (the UK data protection people) deferred to.

The view was - currently the identification of a provider for a particular 
consumer number is not trivial, and if the number is ported then 
potentially requires significant industry knowledge.  If the provider name 
were part of the SIP URL then this would be trivial and so would need 
end-user consent, along with all other PII.  However this was only a 
matter of moving from not trivial to trivial and so could be avoided by 
using a non-trivial URL.  They went on to say that if a WHOIS lookup were 
required to make the connection between the SIP URL and the provider then 
this was not trivial and so there would not be a problem.

I argued (quite strongly) that for a technical person the distinction 
between trivial and non-trivial in this issue was very fine.  However the 
view of the regulator was that it was about how trivial/non-trivial it was 
for the average person in the street, not a technical person.

Strange I know, but it is something we are constrained by.  Personally I 
do not think the text in the draft needs to change as a result.

Jay Daley
Nominet UK