Subject: [e2md] Proposed agenda change for E2md at Anaheim

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 14:33:24 -0600

Bernie and I discussed the agenda yesterday with the ADs. We are  
considering the following alternative structure for the agenda due to  
the severe time constraints.

What do you folks think?

-------

AGENDA:

1. Administrivia (Chairs, 5 min)
   * Note takers, Jabber scribes
   * Agenda bashing

2. Problem Statement and Example Use Cases -- Bernie, 10 min
     (one slide per topic)
   * General problem statement:    draft-hoeneisen-e164-to-metadata-02
   * unused/void:  draft-ietf-enum-unused-04
   * cnam:  draft-ietf-enum-cnam-08
   * send-n:  draft-bellis-enum-send-n-02

3. Open Issues with E2MD -- Dean, 10 min
    * Issues of DNS characteristics and metadata
         Cacheing properties
         Distribution latency / propagation
         "Globally" interesting (no localized queries)
    * Privacy issues:
         Is the DNS the "right place" for all metadata?
         Can we bound the metadata for public use?
         Can we constrain this with an applicability statement?

3. Open discussion on issues -- 15 min

4. Discussion of Charter -- Bernie -- 15 min

5. Conclusions and polls -- Chairs -- 5 min

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Mar 2010 16:08:03 -0500

Well #3 for 10 min given the time frame strikes me as "end world hunger
issues". You can make a case that alternatively that SIP signaling itself
might be another way to transport metadata this but we seem to be
restraining ourselves to public and private DNS methodologies first which is
OK with me.

I'm very weary of discussions that could drift into policy. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Thursday, March 11, 2010 3:33 PM
To: E.164 To MetaData BOF discussion list
Cc: Robert Sparks; Gonzalo Camarillo
Subject: [e2md] Proposed agenda change for E2md at Anaheim

What do you folks think?

-------

AGENDA:

5. Conclusions and polls -- Chairs -- 5 min
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 15:36:29 -0600

> restraining ourselves to public and private DNS methodologies first  

I think we have two (or perhaps three) classes of metadata under  
discussion.

One class of metadata is the sort of globally-useful asker-independent  
sort of stuff that the DNS thrives on. "Unused" is a perfect example  
of this sort of data. It's like putting the semantics of the  
"placeholder" web page created by most registrars directly into the  
DNS. It's presence indicates that the relevant phone number is in fact  
serviced by the ITAD in question, but that it is not currently mapped  
to a phone number and calling it would be pointless. It's refresh/ 
caching/propagation/TTL characteristics are also perfect for the DNS.

ITAD-identifier (Which ITAD owns this number?)  might well be a member  
of this class, although that;s subject to some debate: some people  
want to use this for a next-hop route identifier, which makes it NOT  
structurally suitable for the DNS. And some people seem to think that  
there might be national restrictions on divulging this information to  
the public or conflicts with LNP structural mandates, making the  
metadata NOT politically suited for the DNS.

CNAM is structurally perfectly suitable for the DNS. But the DNS  
mapping between phone number and calling party name is reversible,  
which has consequences. in classic telephony, caller-ID masking and  
"unlisted" numbers are two distinct services. If one metadatum is used  
for both we could get into a problem where enabling caller-ID  
effectively makes the number publicly listed, and/or making a number  
publicly listed prevents placing a call with caller-ID suppressed.  
This is why we've (IETF) previously said caller-ID (both calling-name  
and calling-number) is better as a SIP level thing, which lets it be  
controlled by the SSP on a call-by-call basis.

Certainly one could obviate some of the these data access concerns by  
hiding the entire DNS from untrusted users, but that's it's own world  
of ugly hack. We see that it might be easier to charter a working  
group that would define multiple data elements, SOME of which might  
require hiding the DNS, than it would be to charter a working group  
that would by definition assume that ALL of its data elements being  
put into the DNS require hiding from the world.

So we have data elements that are 1) structurally and politically  
appropriate for the DNS,  2) structurally appropriate but politically  
questionable for the DNS, such that they might require hiding the DNS  
from untrusted accessors, and 3) Structurally inappropriate for the  
DNS because they require requester-specific response determination,  
immediate propagation, large responses, or other things that the DNS  
just doesn't do well.

The E2MD group has to provide a mechanism that allows for the  
determination of which category each proposed use case falls into, and  
we have to decide how we're going to handle use-cases (like CNAM) that  
aren't quite right for the DNS because of political, not structural,  
concerns. Requiring an applicability statement for the use case that  
restricts a DNS serving that metadata to private use might be a  
reasonable solution. If so, E2MD has to make this distinction on case- 
by-case basis. Other solutions, such as encrypting the data with a key  
known to only a subset of the users of the DNS might also provide  
adequate solutions; such would also have to be addressed on a case-by- 
case basis.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 11 Mar 2010 17:59:39 -0500

I don't buy the argument that it's this WG's task to define what is and is
not appropriate for the use of DNS. OR defining how data may or may not be
used. If there are restrictions on the use of SPID's and CNAM, ITAD's
whatever that is a matter for National Regulatory Authorities period. And as
a reminder the use of the entire ENUM 164.arpa tree are governed by NRA's
for each CC are defined by the MOU between the ITU and the IAB. That
policy..WG don't do policy.

A substantial number of these use cases will not be used in situations where
the data will never ever be visible to the single root DNS but only in
private closed instantiations. Nearly half of the ENUM trees out there and
proposed are in fact non visible. 

It should be apparent that the real use case here for non visible meta data
are those use / business cases that will attempt to substitute E2MD data for
TCAP look ups. I still have my NO TCAP cap BTW. The real problem is that
folks are going off and doing all sorts of crazy things and its time to
standardize the elements and process as we did with ENUM registrations and
go home. This was hopefully to a simple WG to wrap up loose elements that
the ENUM WG didn't want to tackle.

And I remind you that we already have defined how LNP data looks in URI's
and SIP and there seems to be no problem there. RFC 4694

I think my suggestion of text to punt this entire issue in the charter made
more sense. It should go back in.

Distribution of E2MD Data
    
The distribution of E2MD data could be highly restricted or contain
Publically Identifying Information (PII). The NAPTR records developed by the
WG could, in some cases, be inappropriate to be part of the RFC 3761bis
e164.arpa DNS tree or any portion of the general DNS.  Distribution of this
NAPTR data would be either within a service provider's internal network, or
on a private basis between one or more parties using a variety of well known
security mechanisms to prohibit general public access.
    
If such PII data was distributed in an open DNS system, a national
regulatory body may have jurisdiction. Such a body may choose to restrict
distribution of the data in such a way that it may not pass over that
country's national borders.  How Personally Identifying Information is
collected, distributed and subsequently regulated is out of the scope of the
WG.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, March 11, 2010 4:36 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'; 'Robert Sparks'; 'Gonzalo
Camarillo'
Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 17:49:54 -0600

> policy..WG don't do policy.

No, we don't do policy. We define protocols for the Internet.

> proposed are in fact non visible.

The counter-argument:  they ought to be using some sort of industry- 
forum web-service API for looking up this data, not the DNS. Or if  
they want to use a hacked-up DNS, they needn't waste our time with it.  
We (IETF) DO NOT DO PROTOCOLS FOR PRIVATE NETWORKS. If we're going to  
do a protocol, it is going to have general applicability, have a  
thorough security analysis including a threat model and defenses  
against identified threats where possible, and come with warning  
labels about inappropriate usage or indefensible threats.

> and SIP and there seems to be no problem there. RFC 4694

I didn't say that we couldn't handle LNP. I just said that some people  
have raised questions about how LNP data interacts with E2MD, and that  
as a consequence, we may have to be prepared to answer those questions.

> more sense. It should go back in.

Fine, but from what the ADs told us on yesterday's call. don't count  
on getting a working group formed as a result. We're going to have to  
confront their concerns and come up with well-reasoned answers, not  
just tell them to stop being silly.

> collected, distributed and subsequently regulated is out of the  

Perhaps the above could be recast in a way less likely to draw fire.

How about:

---
Some of the metadata standardized by E2MD may be subject to policy  
constraints within certain administrative jurisdictions, such as  
national boundaries. When such policy constraints exist, it is the  
responsibility of E2MD operators to comply with those constraints on  
the handling of metadata. The E2MD working group will not attempt to  
anticipate or mandate such policies. Rather, it is assumed that if  
policy constraints exist for access to the metadata in an E2MD  
database, then such policy will be enforced by the E2MD operator  
through enforcement of access controls on the entire E2MD database  
affected by the policy constraints. In particular, the E2MD working  
group will not address AAA issues within the E2MD framework.
---

Note hoe the above states that their might be E2MD databases that have  
restricted access and are not part of teh general ENUM tree, but  
doesn't rub their noses in it. Makes it potentially easier for them to  
pretend they didn't notice.

Or possibly in the RFC we might say:

----
Security Considerations

The data in the E2MD database may or may not require privacy,  
integrity protection, or authentication. Such protections, if  
required, are not addressed by this specification, but are left to the  
operators of the affected E2MD systems to implement using well-known  
methods including walled gardens, private networks, firewalls, fear,  
uncertainty, doubt, and general obfuscation. If users put data into  
E2MD or rely on the data in E2MD in such a way that, when compromised,  
any damage results, don't blame the IETF because we warned you right  
here.

This specification contains no further analysis of the threat models  
posed by unauthorized access to the E2MD databases because frankly, if  
you're running E2MD, then you wouldn't understand the analysis and we  
chose not to bother writing it up.
---

Does that about sum it up?

--
Dean

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 12 Mar 2010 01:22:33 +0000

Hi Dean, Richard, ADs, folks,
Re. IETF does not do limited applicability protocols.
Of course it doesn't (well, except for some SIP extensions :).

However, I note this from section 2.4.3.1 of the current 3761bis-05:

"   Finally, any Enumservice type that starts with the facet "P-" is
   intended for use exclusively on private networks.  As such, NAPTRs
   containing Enumservice types starting "P-" should not be seen on the
   global Internet.  Even if an ENUM client recognizes and can engage in
   the Enumservice, it may be incapable of resolving the URI generated
   by the containing NAPTR.  These Enumservices WILL NOT be registered.

   Such Enumservices MUST NOT be provisioned in any system that provides
   answers to DNS queries for NAPTR resource record sets from entities
   outside the private network context in which these Enumservices are
   intended for use.  Unless an ENUM client is sure that it is connected
   to the private network for which these NAPTRs are provisioned and
   intended, it MUST discard any NAPTR with an Enumservice type that
   starts with the "P-" facet.
"

This was pulled in so that those people who insist on doing perverse
things in the privacy of their own networks can tag the content so the
vicar knows not to attempt to parse it.

This privacy (or not) spat is different, and the DDDS application is
going to be different, but I don't see why we can't leverage this kind
of approach.

We now return you to ...

all the best,
  Lawrence

On 11 Mar 2010, at 23:49, Dean Willis wrote:
> The counter-argument:  they ought to be using some sort of industry-forum web-service API for looking up this data, not the DNS. Or if they want to use a hacked-up DNS, they needn't waste our time with it. We (IETF) DO NOT DO PROTOCOLS FOR PRIVATE NETWORKS. If we're going to do a protocol, it is going to have general applicability, have a thorough security analysis including a threat model and defenses against identified threats where possible, and come with warning labels about inappropriate usage or indefensible threats.
> 
>> 
> I didn't say that we couldn't handle LNP. I just said that some people have raised questions about how LNP data interacts with E2MD, and that as a consequence, we may have to be prepared to answer those questions.
> 
>> 
> Fine, but from what the ADs told us on yesterday's call. don't count on getting a working group formed as a result. We're going to have to confront their concerns and come up with well-reasoned answers, not just tell them to stop being silly.
> 
> Some of the metadata standardized by E2MD may be subject to policy constraints within certain administrative jurisdictions, such as national boundaries. When such policy constraints exist, it is the responsibility of E2MD operators to comply with those constraints on the handling of metadata. The E2MD working group will not attempt to anticipate or mandate such policies. Rather, it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator through enforcement of access controls on the entire E2MD database affected by the policy constraints. In particular, the E2MD working group will not address AAA issues within the E2MD framework.
> ---
> 
> Note hoe the above states that their might be E2MD databases that have restricted access and are not part of teh general ENUM tree, but doesn't rub their noses in it. Makes it potentially easier for them to pretend they didn't notice.
> 
> 
> 
> The data in the E2MD database may or may not require privacy, integrity protection, or authentication. Such protections, if required, are not addressed by this specification, but are left to the operators of the affected E2MD systems to implement using well-known methods including walled gardens, private networks, firewalls, fear, uncertainty, doubt, and general obfuscation. If users put data into E2MD or rely on the data in E2MD in such a way that, when compromised, any damage results, don't blame the IETF because we warned you right here.
> 
> This specification contains no further analysis of the threat models posed by unauthorized access to the E2MD databases because frankly, if you're running E2MD, then you wouldn't understand the analysis and we chose not to bother writing it up.
> ---
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 21:47:51 -0600

> Of course it doesn't (well, except for some SIP extensions :).

I feel so guilty about those!

>   by the containing NAPTR.  These Enumservices WILL NOT be registered.

As we noted in SIP, the P-headers were one of our more egregious  
mistakes. The header "P-" might as well mean "permanent".

> going to be different, but I don't see why we can't leverage this kind

Interesting.

One approach would be to use conventional-looking NAPTR record with a  
new P-service  to return an HTTP URI, which, on an authenticated GET,  
could return a relatively large XML document that contains all the  
perverse bits of metadata we might want.

This approach kills multiple birds with one stone:

1) It keeps the thing in ENUM a URI.

2) It mitigates the "large DNS response problem:.

3) It allows an authentication check before revealing sensitive  
information, suitable for use on the big-I Internet.

4) It allows Daryl Malas' egress-route thingy to return requester- 
differentiated answers (ok, this only SORTOF works, because the URI  
might well be in the wrong domain for returning anything useful,  
necessitating an HTTP "transparent proxy" to make it work right).

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Fri, 12 Mar 2010 17:06:28 +1300

> policy..WG don't do policy.

I completely agree.  We are discussing the hypothetical situation where *some* authorities (I use the term loosely) *may* decide to make *some* parts of this protocol not suitable for public DNS.  Exactly the same outside context issue applies to ENUM and probably many other protocols.

That is not a specific privacy concern for this protocol.

cheers
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Mar 2010 23:00:24 -0600

On Mar 11, 2010, at 10:06 PM, Jay Daley wrote:

> I completely agree.  We are discussing the hypothetical situation  
> where *some* authorities (I use the term loosely) *may* decide to  
> make *some* parts of this protocol not suitable for public DNS.   
> Exactly the same outside context issue applies to ENUM and probably  
> many other protocols.
>

Okay, so if you have an "unlisted" phone number for which you paid  
extra money, do you really want your name and phone number listed  
together in a searchable fashion in the DNS? Is that a privacy  
concern? If so, then we DEFINITELY have privacy concerns around the  
CNAM use case.

How about you're making a phone call and have turned on the"'withold  
caller ID" function, but the associated calling name is in the DNS and  
can be queried? Is that a privacy concern? If so, then we MAY have  
even more privacy concerns around the CNAM use case.

Do you want to advertise exactly how your ISDN trunk line is  
provisioned and what services are associated with it? If so, then we  
MAY have some privacy concerns around the SPID use case (depending on  
how the SPID is formatted).

Would you want your operator to add your billing address,  
authentication key, account number (which can correlate to other  
records and reveal "private" phone numbers through a cross match) or  
other personal information to the DNS? If not, then you MAY want to  
have somebody review proposed new metadata elements for compliance  
with privacy rules before the new elements are registered with IANA  
and therefore made into standards. Or you might want an applicability  
statement somewhere in the specification that says "If you put this  
information into a DNS, it MUST be a private DNS, by which we mean  
(insert your favorite list of what it means to be a private DNS here)."

Do our other use cases have privacy concerns? They very well might.  
Judging by the apathy level of the people who have been proposing this  
stuff, it wouldn't surprise me a bit. So how is the E2MD working group  
going to discover these issues, and what sort of mechanism or guidance  
are we going to offer implementors in our protocol specification to  
help them deal with those issues? We have to have some sort of answer  
to those questions before the IESG and IAB will let us form an IETF  
working group -- and saying "Those are just implementation problems"  
IS NOT AN ACCEPTABLE ANSWER. If we don't have a better answer, we will  
NOT have a working group.

If we have the assumption that all E2MD metadata is always held only  
in private DNS servers that can be queried only by carrier systems and  
that they'll never misconfigure something that leaks information, then  
we don't have any worries. Of course, we also don't have a big-I  
Internet protocol, so we don't need to be doing this in the IETF (and  
we won't be getting a working group). Go bother the ITU or some other  
standards body who cares about intranets and phone networks. But if  
you want to develop an Internet protocol, you have to realize that the  
work requires a detailed Security Considerations section, which  
includes a threat model, risk assessment, and detailed guidance on how  
to keep those threats from becoming real damages. It's something  
that's required in EVERY LAST RFC, although it's certainly better done  
in some than in others.

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Fri, 12 Mar 2010 20:10:19 +1300

Apologies in advance if any of this comes across as rude, it is not my intention.

On 12/03/2010, at 6:00 PM, Dean Willis wrote:
> Okay, so if you have an "unlisted" phone number for which you paid extra money, do you really want your name and phone number listed together in a searchable fashion in the DNS? Is that a privacy concern? If so, then we DEFINITELY have privacy concerns around the CNAM use case.

There are three characteristics of your argument that erroneously transposes layer 9 concerns into concerns about this protocol.  They are:

1.  The potential for misuse of this or any other protocol
2.  Nature of the legal entity whose data is published
3.  Local laws on privacy, choice and how they are enforced and complied with.

The best way I can explain this is with an example.  What if someone puts my address into a TXT record under a public DNS tree?  Well, they already have:

	dig nzrs.tel txt
	dig nzrs.tel naptr

The key things to note is that this was my choice under the business model of .tel to publish my work address and email.   I could have chosen to publish my home address under jaydaley.tel, which again is a choice made through the L9 system about which the protocol is ignorant. Someone else could have published my personal details under jaydaley.tel, which is a misuse of both the protocol and the L9 system that the protocol is agnostic about.  A foolish telco might register my phone number under .tel and published my personal details, again a misuse that violates local laws that the protocol is not responsible for.

CNAM is *exactly* the same - there will be appropriate L9 controls and issues around its use that is nothing to do with this protocol.  

From this explanation comes two critical assertions:
  
- This same set of L9 concerns could be similarly transposed into almost any protocol and so clearly they are not specific to a protocol.
- No protocol can reasonably do anything about these concerns

So in other words, this whole issue of privacy is a red herring.  Well intentioned I'm sure, but still a red herring.

kind regards
Jay

> How about you're making a phone call and have turned on the"'withold caller ID" function, but the associated calling name is in the DNS and can be queried? Is that a privacy concern? If so, then we MAY have even more privacy concerns around the CNAM use case.

> Do you want to advertise exactly how your ISDN trunk line is provisioned and what services are associated with it? If so, then we MAY have some privacy concerns around the SPID use case (depending on how the SPID is formatted).
> 
> Would you want your operator to add your billing address, authentication key, account number (which can correlate to other records and reveal "private" phone numbers through a cross match) or other personal information to the DNS? If not, then you MAY want to have somebody review proposed new metadata elements for compliance with privacy rules before the new elements are registered with IANA and therefore made into standards. Or you might want an applicability statement somewhere in the specification that says "If you put this information into a DNS, it MUST be a private DNS, by which we mean (insert your favorite list of what it means to be a private DNS here)."
> 
> Do our other use cases have privacy concerns? They very well might. Judging by the apathy level of the people who have been proposing this stuff, it wouldn't surprise me a bit. So how is the E2MD working group going to discover these issues, and what sort of mechanism or guidance are we going to offer implementors in our protocol specification to help them deal with those issues? We have to have some sort of answer to those questions before the IESG and IAB will let us form an IETF working group -- and saying "Those are just implementation problems" IS NOT AN ACCEPTABLE ANSWER. If we don't have a better answer, we will NOT have a working group.
> 
> If we have the assumption that all E2MD metadata is always held only in private DNS servers that can be queried only by carrier systems and that they'll never misconfigure something that leaks information, then we don't have any worries. Of course, we also don't have a big-I Internet protocol, so we don't need to be doing this in the IETF (and we won't be getting a working group). Go bother the ITU or some other standards body who cares about intranets and phone networks. But if you want to develop an Internet protocol, you have to realize that the work requires a detailed Security Considerations section, which includes a threat model, risk assessment, and detailed guidance on how to keep those threats from becoming real damages. It's something that's required in EVERY LAST RFC, although it's certainly better done in some than in others.
> 
> 
> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 12 Mar 2010 08:23:00 -0600

> So in other words, this whole issue of privacy is a red herring.  Well intentioned I'm sure, but still a red herring.

Perhaps a red herring, but one we have to nail down before the WG will
be authorized.

You are aware that the entire use case for CNAM is to put your private
phone number into the DNS, right? It's not "potentially abusable" like
TXT records. It's "almost sure to be a problem unless the ISP does
something different from standard practice for DNS." When this condition
applies, the protocol has to give guidance, at the very least something
like "If you use this extension to put restricted numbers into the DNS,
you MUST make sure that the DNS tree you are putting them into is not
publicly accessible."

I'm not making this stuff up, and it isn't me we have to convince --
although I do believe that if we can't convince me, the probability of
convincing the IESG and IAB is pretty low.

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Fri, 12 Mar 2010 14:55:43 +0000

> you MUST make sure that the DNS tree you are putting them into is not

There of course has to be some language somewhere which can speak to  
this issue. It can't be ignored or brushed aside as a Layer9+ matter.

However there is an alternative solution which some consider ugly. It  
is possible to encrypt NAPTR records. [Purists *hate* this.] Telnic  
uses this approach in .tel so the public DNS can hold contact data  
which can only be decoded by friends and family. It uses public-key  
crypto: the handshaking and provisioning is left as an exercise for  
the reader. Something that's still on my To Do list is to find out  
what happened to the IDs that were published about this scheme and get  
them out as Informational RFCs.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 12 Mar 2010 11:18:29 -0500

Dean .. This is totally absurd now and it needs to stop. You are essentially
arguing that ENUM should not have been formed at all or that E2MD has no
business in the IETF since it MAY relate to internal carrier
interoperability between the PSTN and SIP.

The original ENUM charter always recognized that the protocol would be used
for this stuff no one had a issue with this until you started this thread.

"
 2. The working group will examine and document the use of RFC 3761 to
facilitate network interconnection for services using E.164 addressing.
The working group will coordinate its activities with other IETF
Working groups, existing or to be chartered, that are investigating elements
of
peering and or interconnection for VoIP or other services that
typically use E.164 addressing.

3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed
by E.164 numbers, for example PSTN call routing and signaling data."

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, March 12, 2010 12:00 AM
To: Jay Daley
Cc: Richard Shockey; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Sat, 13 Mar 2010 08:16:28 +1300

On 13/03/2010, at 3:23 AM, Dean Willis wrote:

> phone number into the DNS, right?

Eh?  ENUM by very definition means putting my private phone number into the DNS.  Are you seriously suggesting the privacy issue is the very existence of a telephone number as a domain name or did you actually mean the data associated with it?

cheers
Jay

> It's not "potentially abusable" like

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 14 Mar 2010 20:57:07 -0400

+1 a good working start. I captures the essence.

-----Original Message-----
From: Bernie Hoeneisen [mailto:[email-masked]] 
Sent: Sunday, March 14, 2010 6:11 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim

On Thu, 11 Mar 2010, Dean Willis wrote:

> constraints within certain administrative jurisdictions, such as national 
> boundaries. When such policy constraints exist, it is the responsibility
of 
> E2MD operators to comply with those constraints on the handling of
metadata. 
> The E2MD working group will not attempt to anticipate or mandate such 
> policies. Rather, it is assumed that if policy constraints exist for
access 
> to the metadata in an E2MD database, then such policy will be enforced by
the 
> E2MD operator through enforcement of access controls on the entire E2MD 
> database affected by the policy constraints. In particular, the E2MD
working 
> group will not address AAA issues within the E2MD framework.

@Rich: Does this work with you?

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Sun, 14 Mar 2010 21:37:05 -0500

On Mar 12, 2010, at 1:16 PM, Jay Daley wrote:

> Eh?  ENUM by very definition means putting my private phone number  
> into the DNS.  Are you seriously suggesting the privacy issue is the  
> very existence of a telephone number as a domain name or did you  
> actually mean the data associated with it?

Let me restate that: Put your private phone number LINKED TO YOUR  
NAME, into the DNS.

So if I want Jay Daley's private number, I can just grep the zone file.

--
Dean

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 15 Mar 2010 10:01:39 +0000

Hi Dean,
 difficult to know where to start, but... ?!?grep the zone file?!? 

- Jay Daley has published this information, through his choice, in a *non-ENUM* domain.
  Otherwise how the heck are you going to find out which number is associated with Jay Daley?
  ENUM is a "forward" directory FROM number TO data/metadata, not the other way around.
  The reverse directory you're looking for would require you to collect the data for every
  ENUM domain in the World.

- to do that you will need to have the zone files for every domain in the world.
  There could be billions of these files.
  Are you going to AXFR them all?
  No-one has an obligation to accept zone file access requests for ENUM domains.
  Certainly, it is unlikely that everyone has any such obligation, and would respond.

- Go bribe his carrier; it's about the only sane way to find out that information.

all the best,
  Lawrence

On 15 Mar 2010, at 02:37, Dean Willis wrote:

> Let me restate that: Put your private phone number LINKED TO YOUR NAME, into the DNS.
>

---

From: [email-masked]
Date: Mon, 15 Mar 2010 13:31:20 +0000

> +1 a good working start. I captures the essence.

I'm happy with the first sentence.   It draws attention to the possibility 
of regulatory and/or privacy issues, without mandating anything.

However, I'm not happy with: "it is assumed that if policy constraints 
exist for access to the metadata in an E2MD database, then such policy 
will be enforced by the E2MD operator through enforcement of access 
controls on the entire E2MD database affected by the policy constraints."

IMHO, "access controls on the entire E2MD database" is too restrictive, 
and unnecessarily constrains the solution space (both by method - "access 
controls", and scope - "entire database").

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2010 15:51:50 -0500

On Mar 15, 2010, at 8:31 AM, [email-masked] wrote:

> I'm happy with the first sentence.   It draws attention to the  
> possibility of regulatory and/or privacy issues, without mandating  
> anything.
>
> However, I'm not happy with: "it is assumed that if policy  
> constraints exist for access to the metadata in an E2MD database,  
> then such policy will be enforced by the E2MD operator through  
> enforcement of access controls on the entire E2MD database affected  
> by the policy constraints."
>
> IMHO, "access controls on the entire E2MD database" is too  
> restrictive, and unnecessarily constrains the solution space (both  
> by method - "access controls", and scope - "entire database").
>

So, you want it to say that the E2MD operator will just have to deal  
with the problem somehow, but that the E2MD working group will give no  
guidance on how they might deal with it?

Or do you want something more like adding "Other mechanisms may be  
applicable, but are outside the scope of the E2MD working group" to  
the text proposed above?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2010 16:05:17 -0500

> difficult to know where to start, but... ?!?grep the zone file?!?

Ok, that's an oversimplification. But E.164 numbers are predictable.  
If I can guess what country you're in (even better if I can guess the  
area code and exchange), then I can just do lookups on each phone  
number until I find the one with your name attached to it.

For example, if you know I have an unlisted phone number at Terlingua  
Ranch (which is served by exchange +1 972 519 xxxx) you only need an  
average of 5,000 lookups to figure out which phone number is my  
unlisted number (and in practice, less than that. since the number is  
in the lower 5,000). Sure, you could make 5,000 phone calls and listen  
for me, but it's a lot easier to write a Perl script to make the DNS  
calls.

This is one of the reasons many companies are loathe to put PTR  
records out there -- they can be reverse-discovered through  
prediction, allowing a competitor or hacker to more easily map your IT  
infrastructure. But such records aren't contractually -protected  
confidential information, like subscriber identity might be. More  
guidance on the risks and how to cover them may well be needed.

Some of our people seem to be saying "There are no risks, and if there  
were, there is no guidance needed because this stuff is all on  
intranets anyhow." This isn't going to get us a working group.

>  ENUM domain in the World.

Jay's free to publish HIS information wherever he wants. AT&T is NOT  
free to publish my information in violation of my "unpublished" phone  
number service for which I pay extra. And if they publish it in an  
easily-hackable way, they're going to face some considerable court  
damages by the time my lawyer gets through with them. Now, I suspect  
they're smart enough to not screw up (after all, look at how good my  
UMTS 850 coverage is), but it is the convention of the IETF that our  
protocols have a reasonable "Security Considerations" section built  
right in to the RFC.

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Tue, 16 Mar 2010 10:29:44 +1300

> Let me restate that: Put your private phone number LINKED TO YOUR NAME, into the DNS.

You are misrepresenting CNAM here.  CNAM only enables the *subscriber name* to be put into the DNS, which is only a private name if the subscriber is a) a natural person an b) in a jurisdiction where that is considered a private data combination.  Even if both tests are met, the regulation of that jurisdiction would include rules for publishing that data combination with such barriers as opt-in by the subscriber.

Even if we go to an extreme and assume all private names are not opted in then what remains is a substantive and important use case of non-private subscriber names, such as those for companies, organisations and other subscribers that are not natural persons.  In my jurisdiction, as with many I suspect, there are rules that *require* companies to accurately identify themselves.

cheers
Jay

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2010 17:21:01 -0500

On Mar 15, 2010, at 4:29 PM, Jay Daley wrote:

> You are misrepresenting CNAM here.  CNAM only enables the  
> *subscriber name* to be put into the DNS, which is only a private  
> name if the subscriber is a) a natural person an b) in a  
> jurisdiction where that is considered a private data combination.   
> Even if both tests are met, the regulation of that jurisdiction  
> would include rules for publishing that data combination with such  
> barriers as opt-in by the subscriber.
>

In the PSTN, even "unlisted" telephone numbers may allow calling-name  
display. In my jurisdiction,  I believe calling name and calling  
number are both presented if the unlisted subscriber has not selected  
an option for blocking calling-number.

> Even if we go to an extreme and assume all private names are not  
> opted in then what remains is a substantive and important use case  
> of non-private subscriber names, such as those for companies,  
> organisations and other subscribers that are not natural persons.   
> In my jurisdiction, as with many I suspect, there are rules that  
> *require* companies to accurately identify themselves.
>

I never said the use case was invalid.

I said, and am continuing to say, that some use cases require guidance  
above and beyond "don't be stupid" in our protocol specifications.  
Providing such guidance means that the work needs a detailed security  
analysis with a threat model, and needs defenses ranging from "must  
implement" specifications through "best practice" guidelines to be  
documented and published in conjunction with the specification.

The proposed working group MUST embrace doing appropriate security  
analysis and MUST commit to providing appropriate defenses as part of  
its deliverable work scope. It is unacceptable to charter a working  
group that refuses to acknowledge these responsibilities and commit to  
meeting them.

We don't have to have an answer as to what specific technical  
solutions nor operational guidelines we will produce; we can't know  
those in advance of doing the work. However, we also cannot declare in  
our charter that such concerns are "out of scope". They are not out of  
scope, and MUST be explicitly part of the scope of the working group,  
or the working group is not going to be chartered within the IETF.

I don't care if you think I'm being paranoid. The Security Area  
directors are professionally far more paranoid than I could ever  
manage, truly "These are paid experts, kids, do not attempt to be this  
paranoid yourself" sorts of people. THEY WILL BE PLACING REQUIREMENTS  
ON OUR WORK. If we are not prepared to step up and work through those  
requirements, then we might as well just stay home, because out  
specifications will NOT be published as standards-track RFCs if we  
don't make these people happy. That's the process. I did not invent  
this process. But I am here to help make sure that we come up with a  
work plan that is consistent with the process.

--
Dean