Subject: [Enum] Last minute comments on draft-shockey-enum-privacy-security-00.txt

From: John Morris <[email-masked]>
Date: Mon, 18 Nov 2002 00:57:06 -0500

Rich, all,

Let me offer a few last minute reactions to the enum-privacy-security 
draft.  I unfortunately have a conflict with the Monday WG meeting and so 
cannot offer these in person.  Although until now I've not actively 
participated in discussions on this list, I've been looking at privacy 
issues surrounding ENUM for some time.  I'd be interested in contributing 
to further work on this draft.

Broadly speaking, there are two distinct areas where privacy concerns could 
be implicated by ENUM.  First is the question of what potentially private 
information must be exposed in the context of an ENUM transaction itself (a 
lookup in the DNS as part of, possibly, the initiation of a voice or other 
communication).  Second is the question of what info is required (by a 
national ENUM authority) to authorize the insertion of an E.164/ENUM record 
into the DNS.  Let me comment on these two areas separately.

With the first area, the breakout of three conceptions of ENUM offered in 
the internet-draft is, I think, very constructive for thinking about 
privacy.  Looking at the "second view" of ENUM first -- the "called party 
control" approach in section 3.2 -- this appears to be the most privacy 
protecting of the three approaches.  For a given E.164 number, the only 
information that must be exposed in the DNS is a URI pointer to a proxy 
with which the called party presumably has a pre-existing contractual 
relationship.  That contractual relationship will govern how much privacy 
protection the proxy will afford, and presumably the called party can 
contract with the proxy to respond to ENUM queries according to rules set 
by the called party.  There are of course security (and thus privacy) 
concerns about whether the info stored by the proxy is open to attack.  But 
assuming those concerns can be addressed satisfactorily, private contact 
information is only released or exposed as directed by the called party.

An important caveat is that for this "called party control" approach to 
meaningfully protect privacy, there cannot be unreasonable restrictions 
placed by national authorities on who can operate proxies that are pointed 
to by ENUM DNS records.  In other words, the privacy protecting aspects of 
this approach might well be lost if a national authority only permits one 
or a limited number of companies to operate proxies pointed to by an ENUM 
DNS record.  Ideally, even an individual running a SIP proxy in his or her 
home should be able get an ENUM DNS record to point to that proxy.

The "first" view of ENUM (as a number translation database in section 3.1) 
raises only limited privacy concerns, especially assuming the "called party 
control" approach is also a viable option.  If one wants to be reachable 
through the ENUM system but does not want to run or contract with a proxy, 
one has to be willing to publish at least a single contact method in the 
DNS.  If the "called party control" approach is for some reason prohibited 
by a national authority, then this "number translation" approach is more 
coercive (to use ENUM, you MUST publish one contact method for all the 
world to see).  Thus, it is important for the called party control approach 
to be an option.

The "third" view of ENUM -- the calling party control approach -- is 
superficially the most privacy invasive (because it anticipates that all or 
many of an individual's contact methods would be published in the DNS).  If 
this were the only way one could obtain ENUM services, this would be very 
problematic.  But, so long as "called party control" is a viable option, 
then "calling party control" does not present significant privacy problems 
-- because only those individuals who choose to publish all methods of 
contact (such as, for example, real estate agents in the U.S., or employers 
who want their employees to be maximally available to customers) will 
utilize this approach.

Although not a significant concern of the IETF ENUM WG, it is this third 
approach to ENUM that garners the most criticism by traditional privacy 
advocates.  From the outside, this third approach looks like a open 
invitation to data mining (and spam, etc.) by publishing lots of contact 
info in the public DNS system.  For ENUM to move beyond such marketplace 
criticisms, it will be important to make clear that things like the "called 
party control" option can make ENUM a very privacy-friendly technology.

Turning to the second broad area of privacy concern, all of the 
considerations about how privacy protecting ENUM can be could well be made 
moot if a national authority implementing ENUM requires onerous disclosure 
(especially public disclosure) as a requirement to obtain an E.164 ENUM/DNS 
entry in the first place.  In other words, if a fully populated WHOIS type 
database were required in order to obtain any ENUM entry in the DNS, then 
the privacy protecting features of the "called party control" approach 
could be destroyed.

The ENUM-privacy-security Internet-Draft proposes (in Section 4) that 
national ENUM implementations should implement a form of WHOIS for 
technical contact data.  Such a recommendation to national ENUM authorities 
could be understood to suggest that no ultimate called party should  be 
able to stand anonymously behind a proxy server.  I don't think the draft 
is intended to suggest this, but any finally recommendation should be clear 
that there is no need for the identity of an ultimate ENUM subscriber/user 
to be published in a publicly available WHOIS database.

Sorry that these comments are coming in only hours before the WG meeting 
(which I cannot attend because of a conflict).  I'd be happy to discuss 
this more on the list.

John Morris

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 18 Nov 2002 09:40:26 -0500

John,

This caught my attention:

> ...Ideally, even an individual running a SIP proxy in his or her 

Am I correct in thinking this means that the access model associated
with provisioning assume an authentication model which scales to the
size of the delegation scoped end-points?

Eric

---

From: John Morris <[email-masked]>
Date: Mon, 18 Nov 2002 11:03:20 -0500

>size of the delegation scoped end-points?

I unfortunately cannot answer whether the anticipated authentication model 
will in fact be able to scale, but I certainly am hopeful that individual 
end points will have an ability to register an individual SIP proxy. I can 
certainly see that parts of the authentication process could be delegated 
(perhaps along the lines of domain name registries/registrars).

I hope this helps.

John

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 18 Nov 2002 11:23:20 -0500

> ... cannot answer whether the anticipated authentication model 
> will in fact be able to scale ...

OK.

> I hope this helps.

No.