Subject: [e2md] Updated Charter Proposal

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 16 Mar 2010 00:16:11 +0100 (CET)

Hi,

Thanks for all the feedback and discussions on- and off-list!

Based on these discussions, Dean and myself made an update to the proposed 
charter and we would like to know your opinion about it. The substantial 
changes were in section "Scope of Working Group". We also added there 
paragraphe about security considerations, which might trigger some further 
discussions...

The whole currently proposed charter can be fetched from

   http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt

For your convenience you can find a copy-paste of the section "Description of 
Working Group" below.

cheers,
  Bernie

----

Description of Working Group
----------------------------

Abstract
--------

E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI
Mapping) in either public or private instantiations to provide
additional information about E.164 (telephone) numbers. In some use
cases, information (metadata) about E.164 numbers cannot be expressed
as a URI (Uniform Resource Identifier) as required by the ENUM DDDS
(Dynamic Delegation Discovery System) described in RFC 3761bis.
Therefore, E2MD will define a different mechanism for expressing
metadata. The initial expectation is that this mechanism will be a new
DDDS for metadata, based on RFC 3761bis, that returns standardized
metadata instead of URIs.

Background
----------

ENUM provides an identifier mapping mechanism to map E.164 numbers to
Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically
used to look up the services associated with an E.164 number, each of
which is represented by a URI.

However, there is more information about a telephone number that may
be useful when establishing a communications session using that phone
number. For example, this information might be used to decide or what
sort of communications session to establish using that phone number,
or whether to accept a communications session offered by someone using
that phone number. We refer to this information as "metadata". Several
example use cases for metadata have been documented as Internet
drafts, and will be considered during the work of E2MD for inclusion
in the group's work product.

Typically, this metadata information is such that it cannot be
described using a URI consistent those returned by a lookup using RFC
3761bis, making a direct use of RFC 3761bis innapropriate. However,
the basic lookup mechanism of RFC 3761bis appears to provide a good
foundation for a metadata service, so E2MD will work from this basis.

Previous Enumservice proposals tried to resolve these issues by using
the 'data' URI scheme or inventing completely new URI schemes, however
it is believed that such proposals do not satisfy the general use case
for metadata, and a new approach is required.

Problem Statement
-----------------

Typically, the phone-number asssociated metadata is such that it
cannot be described using a URI consistent those returned by a lookup
using RFC 3761bis, making a direct use of RFC 3761bis inapropriate.
However, the basic lookup mechanism of RFC 3761bis appears to provide
a good foundation for a metadata service, so E2MD will work from this
basis. The initially favored approach is to define an additional ENUM
service (E2M) that maps phone-numbers to metadata that will operate in
parallel to the current ENUM service (E2U), which maps phone numbers
to URIs.

Current proposals for metadata to be addressed by E2MD include (but
are not limited to) Enumservices for 'cnam' to provide information
about the calling party name,  'unused' to provide a hint that a
number is not in use, 'send-n' to describe the structure of an ENUM
tree, 'spid' to describe a service provider identifier, 'itad' to
describe an internet telephony administrative domain, etc.

Scope of Working Group
----------------------

The E2MD Working Group is chartered to develop a new Dynamic
Delegation Discovery System (DDDS) application that can be used with
DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will
provide the means for data related to E.164 numbers that do not fit
into the classic concept of ENUM (E2U).

The E2MD specifications shall reuse as much as possible from the ENUM
DDDS and its IANA registry specification. Along with the E2MD DDDS
application a new IANA registry will be specified for registration of
E2MD services. The registration policy shall be Expert Review and
Specification Required (see RFC 5226), similar to those specified for
Enumservice (E2U) registrations.

Limitations of the DNS are to be considered while defining the
protocol; in particular packet size restrictions of deployed DNS
transport.

E2MD shall not be specified as a general purpose lookup nor as bulk
transfer protocol, but rather focus on clear use cases related to
E.164 numbers.

The E2MD working group will, for each specification published, follow
IETF practices and include a thorough Security Considerations
section. These Security Considerations sections will include detailed
threat models. Further, the specifications will include "MUST
Implement" defensive mechanisms, operational guidelines, and/or
applicability statements relative to particular metadata as
appropriate.

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.  In
particular, the E2MD working group will not address AAA issues within
the E2MD framework.

A major product of the E2MD working group is to define a process and
review model for the registration of new E2MD services with
IANA. Until this process is in place, the E2MD working group will act
as the central point for discussion and review of proposals for new
E2MD services.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Mar 2010 11:32:33 -0400

RS> This is redundant we all know that there are security requirements for
RFC's. We don't need detailed threat models this is DNS technology that is
well documented. We know how the DNS is used.

I think this section needs to be removed. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Hoeneisen
Sent: Monday, March 15, 2010 7:16 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] Updated Charter Proposal

Hi,

For your convenience you can find a copy-paste of the section "Description
of 
Working Group" below.

cheers,
  Bernie

----

Abstract
--------

Background
----------

Problem Statement
-----------------

Scope of Working Group
----------------------

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

---

From: [email-masked]
Date: Tue, 16 Mar 2010 15:37:45 +0000

> I think this section needs to be removed. 

+1

I'm fine with the new text that replaces the bit I complained about 
yesterday.

Ray

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 14:41:06 -0500

> I think this section needs to be removed.

This section was specifically added because postings on our E2MD  
discussion list seemed to indicate that some of our participants   
thought that E2MD should be somehow excepted from these requirements  
and explicitly say so in our charter.

Going forward, we need a clear consensus that E2MD will be a "good  
citizen of the IETF" and play by the rules. If putting this explicitly  
into our charter helps both us and the IESG/IAB understand that we  
have developed such a consensus, then it is useful to have it there.

Seriously, there is a question here.

Are we going to look at each use case separately, and say "This use  
case is OK for the public Internet, but that use case is only ok in  
Intranets, and this other use case is so sensitive that it needs per- 
element encryption?" Or are we going to adopt a blanket policy of  
saying "Gee, some of our data might be sensitive. If you think it is  
sensitive, just don't show it to anybody who might abuse it."

If the former, then we need to develop  guidelines  by which an expert  
reviewer can make a decision about any proposed future registration  
(Specification Required), or by which the IETF as a whole could make  
such a call (Standards Track).

--
Dean

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Tue, 16 Mar 2010 20:51:24 +0100 (CET)

Hi Rich

I see your point. However, this is at most redundant for specifications 
published as RFC, but other specifications are not automatically covered 
by RFC 3552 / BCP 72.

How about replacing the 2nd sentence with a reference to the RFC 3552 / 
BCP 72, such as?

   The E2MD working group will, for each specification published, follow
   IETF practices and include a thorough Security Considerations section as
   defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on
   Security Considerations".

Can we all agree to this?

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 14:51:56 -0500

> well documented. We know how the DNS is used.

Apparently some people either don't understand how the DNS works, or  
haven't thought the threat models for all possible metadata. I  
certainly fall into at least the second camp, because I don't yet know  
what "all possible metadata" encompasses, and I'm pretty sure I can  
imagine some stuff that is potentially problematic. Remember, people  
will be adding new metadata long after "we" (the E2MD working group)  
are gone. I'm sure somebody will come up with something pretty  
crazy . . .

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Mar 2010 16:09:22 -0400

Of course this is documented custom and practice in the IETF. 

-----Original Message-----
From: 'Bernie Hoeneisen' [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 3:51 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Updated Charter Proposal

Hi Rich

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 15:23:09 -0500

On Mar 16, 2010, at 2:51 PM, Bernie Hoeneisen wrote:

> Hi Rich
>
> I see your point. However, this is at most redundant for  
> specifications published as RFC, but other specifications are not  
> automatically covered by RFC 3552 / BCP 72.
>
> How about replacing the 2nd sentence with a reference to the RFC  
> 3552 / BCP 72, such as?
>
> section as

I think you're missing the point I was trying to make.

The E2MD group is most likely going to develop a process for  
registering future metadata extensions.

Part of this process needs to be guidance on how to handle security  
considerations for metadata. I believe this needs to include the  
decision process that we used in handling the use-cases that are  
currently before us. If, in considering the current use cases we say  
"Gee, this is just DNS data, and we ALL know the properties of DNS  
data, so these use cases need no review" then that's the decision  
process we're leaving to future reviewers of E2MD proposals. If no  
more consideration is needed, then why don't we just open the E2MD  
registration process up as first-come, first-served and be done with it?

--
Dean

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 16 Mar 2010 21:44:28 +0100 (CET)

Dean,

We have a similar case for Enumservice registrations, see:

   http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide

The e2md registration process will be based in that document. The 
following section in that document address your concerns, such as:

---

3.3. Security Requirements

    An analysis of security issues is REQUIRED for all registered
    Enumservices.  (This is in accordance with the basic requirements for
    all IETF protocols.)

    All descriptions of security issues MUST be as accurate and extensive
    as feasible.  In particular, a statement that there are "no security
    issues associated with this Enumservice" must not be confused with
    "the security issues associated with this Enumservice have not been
    assessed".

    There is no requirement that an Enumservice must be completely free
    of security risks.  Nevertheless, all known security risks MUST be
    identified in an Enumservice Specification.

    The security considerations section of Enumservice Specifications is
    subject to continuing evaluation and modification, in accordance with
    Section 11.7.

    Some of the issues to be looked at in a security analysis of an
    Enumservice are:

    1.  Complex Enumservices may include provisions for directives that
        institute actions on a user's resources.  In many cases provision
        can be made to specify arbitrary actions in an unrestricted
        fashion which may then have devastating results (especially if
        there is a risk for a new ENUM look-up, and because of that an
        infinite loop in the overall resolution process of the E.164
        number).

    2.  Complex Enumservices may include provisions for directives that
        institute actions which, while not directly harmful, may result
        in disclosure of information that either facilitates a subsequent
        attack or else violates the users' privacy in some way.

    3.  An Enumservice might be targeted for applications that require
        some sort of security assurance but do not provide the necessary
        security mechanisms themselves.  For example, an Enumservice
        could be defined for storage of confidential security services
        information such as alarm systems or message service passcodes,
        which in turn require an external confidentiality service.

---

5.5. Security Considerations (MANDATORY [section in the specification])

    A section explaining any potential security threats that are unique
    to the given registration MUST be included.  This MUST also include
    any information about access to Personally Identifiable Information
    (PII).

    An Enumservice Specification SHOULD NOT include general and obvious
    security recommendations, such as securing servers with strong
    password authentication.

    [RFC3552] provides guidance to write a good Security Considerations
    section, Section 10.2 of this document contains guidance specific to
    Enumservice registration.

---

7.2. Review Guidelines

    Generally, the "Expert Review" process of an Enumservice MUST follow
    the guidelines documented in Section 3.3 of "Guidelines for Writing
    an IANA Considerations Section in RFCs" [RFC5226].

    The experts MUST evaluate the criterion as set out in [RFC5226], as
    well as consider the following:

    o  Verify conformance with the ENUM specification
       [I-D.ietf-enum-3761bis].

    o  Verify that the requirements set out in this document (Section 3,
       Section 5) are met.  This includes check for completeness and
       whether all the aspects described in Section 3 and Section 5 are
       sufficiently addressed.

    [...]

---

10.2. Enumservice Security Considerations Guideline

    [I-D.ietf-enum-3761bis] already outlines security considerations
    affecting ENUM as a whole.  Enumservice Specifications do not need to
    and SHOULD NOT repeat considerations already listed in that document.
    However, Enumservice Specifications SHOULD include a reference to
    that section.

    ENUM refers to resources using existing URI Schemes and protocols.
    Enumservice Specifications do not need to and SHOULD NOT repeat
    security considerations affecting those protocols and URI Schemes
    themselves.

    However, in some cases, the inclusion of those protocols and URI
    Schemes into ENUM specifically could introduce new security issues.
    In these cases, those issues or risks MUST be covered in the
    "Security Considerations" section of the Enumservice Specification.
    Authors should pay particular attention to any indirect risks that
    are associated with a proposed Enumservice, including cases where the
    proposed Enumservice could lead to the discovery or disclosure of
    Personally Identifiable Information (PII).

----

Anything missing?

cheers,
  Bernie

On Tue, 16 Mar 2010, Dean Willis wrote:

>> published as RFC, but other specifications are not automatically covered by 
>> RFC 3552 / BCP 72.
>> 
>> How about replacing the 2nd sentence with a reference to the RFC 3552 / BCP 
>> 72, such as?
>> 
> The E2MD group is most likely going to develop a process for registering 
> future metadata extensions.
>
> considerations for metadata. I believe this needs to include the decision 
> process that we used in handling the use-cases that are currently before us. 
> If, in considering the current use cases we say "Gee, this is just DNS data, 
> and we ALL know the properties of DNS data, so these use cases need no 
> review" then that's the decision process we're leaving to future reviewers of 
> E2MD proposals. If no more consideration is needed, then why don't we just 
> open the E2MD registration process up as first-come, first-served and be done 
> with it?
>
> --
> Dean
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Mar 2010 17:01:17 -0400

Can we just get the WG formed first? 

What instructions the WG gives to the expert reviewers should be covered in
the drafts not the charter and we have a good start for doing that in the
enumservice registration documents.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 4:23 PM
To: Bernie Hoeneisen
Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Updated Charter Proposal

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 16:59:21 -0500

> Can we just get the WG formed first?

Have to have an acceptable charter to form a WG.

> enumservice registration documents.

Fair question.

Can the charter say that the WG expects to have to develop  
instructions for expert reviewers and expects to draw heavily on the  
enumservice registration documents in doing so?

If it does, I think this would go a long way towards answering (or at  
least informing) critics  who think that E2MD believes this has  
already been completely resolved.

--
Dean

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Tue, 16 Mar 2010 23:07:25 +0100 (CET)

Dean,

On Tue, 16 Mar 2010, Dean Willis wrote:

> Can the charter say that the WG expects to have to develop instructions for 
> expert reviewers and expects to draw heavily on the enumservice registration 
> documents in doing so?

I believe the current charter proposal already covers this implicitely:

   "The E2MD specifications shall reuse as much as possible from the ENUM
   DDDS and its IANA registry specification."

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 18:00:16 -0500

On Mar 16, 2010, at 5:07 PM, Bernie Hoeneisen wrote:

>> instructions for expert reviewers and expects to draw heavily on  
>> the enumservice registration documents in doing so?
>

We've learned something about "implicit" over the years, have we not?

--
Dean

---

From: [email-masked]
Date: Wed, 17 Mar 2010 09:57:00 +0000

> Can we all agree to this?

That works for me.

Ray

---

From: Jay Daley <[email-masked]>
Date: Thu, 18 Mar 2010 09:12:41 +1300

> > Can we all agree to this?

me too.
Jay

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