WG Review: Domain Boundaries (dbound)

[The IESG <[e-mail]>]

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-16.

Domain Boundaries (dbound)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Barry Leiba <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: http://www.ietf.org/mailman/listinfo/dbound
  Archive: http://www.ietf.org/mail-archive/web/dbound

Charter:

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related. The meaning of
"related" in this context is not a unitart concept. The DBOUND working
group will develop one or more solutions to this family of problems,
and will clarify the types of relations relevant.

For example, it is often necessary or useful to determine whether
example.com and foo.example.com, or even example.net, are subject to
the same administrative control. To humans, the answer to this may be
obvious. However, the Domain Name System (DNS), which is the service
that handles domain name queries, does not provide the ability to mark
these sorts of relationships. This makes it impossible to discern
relationships algorithmically. The right answer is not always "compare
the rightmost two labels".

Applications and organizations impose policies and procedures that
create additional structure in their use of domain names. This creates
many possible relationships that are not evident in the names
themselves or in the operational, public representation of the names.

Prior solutions for identifying relationships between domain names have
sought to use the DNS namespace and protocol to extract that information
when it isn't actually there.  See the "Additional Background
Information" section, below, for more details.

For the purpose of this work, domain names are identifiers used by
organizations and services, independent of underlying protocols or
mechanisms.  We define an "organizational domain" to be a name that is
at the top of an administrative hierarchy, defining transition from one
"outside" administrative authority to another that is "inside" the
organization.

The current way most of this is handled is via a list published at
publicsuffix.org, and the general goal is to accommodate anything people
are using that for today.  However, there are broadly speaking two use
patterns. The first is a "top ancestor organization" case. In this case,
the goal is to find a single superordinate name in the DNS tree that can
properly make assertions about the policies and procedures of 
subordinate names. The second is to determine, given two different 
names, whether they are governed by the same administrative authority. 
The goal of the DBOUND working group is to develop a unified solution, 
if possible, for determining organizational domain boundaries. However, 
the working group may discover that the use cases require different 
solutions. Should that happen, the working group will develop those 
different solutions, using as many common pieces as it can.

Solutions will not involve the proposal of any changes to the DNS
protocol.  They might involve the creation of new resource record types.

This working group will not seek to amend the consuming protocols
themselves (standards for any web, email, or other such protocols)
without rechartering, and such rechartering will only be considered after
completion of the base work.

The working group has a pre-IETF draft to consider as a possible
starting point: draft-sullivan-dbound-problem-statement

Milestones:
- TBD


Additional Background Information
---------------------------------
[to be moved to a Wiki on chartering]

The concept of an administrative boundary is by definition not present
in the DNS.  Relying on the DNS to divine administrative structure thus
renders such solutions unreliable and unnecessarily constrained.  For
example, confirming or dismissing a relationship between two domain
names based on the existence of a zone cut or common ancestry is often
unfounded, and the notion of an upward "tree walk" as a search mechanism
is, therefore, unacceptable.

Currently, the most well known solution in existence is the Public
Suffix List (PSL).  The PSL is maintained by a web browser producer and
is kept current by volunteers on a best-effort basis.  It contains a
list of points in the hierarchical namespace at which registrations take
place, and is used to identify the boundary between so-called "public"
names (below which registrations can occur, such as ".com" or ".org.uk")
and the private names (organizational names) that domain registrars 
create within them.  When this list is inaccurate, it exposes a 
deviation from reality that degrades service to some and can be 
exploited by others.  As the PSL is the de-facto resource, and as there 
is not a more comprehensive, alternative solution for relationship 
identification, the PSL has often been misused to accomplish things 
beyond its capabilities.  For example, there is no way to confirm the 
relationship between two domain names -- the PSL may only signal that 
there is or is not a public boundary between the two. Additionally, 
there are questions about the scalability, central management, and 
third-party management of the PSL as it currently exists.

In terms of specific use cases, within the realm of email there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (at some point in the namespace above it), in
order to identify a deterministic location where some sort of statement
of policy regarding that FQDN can be found.  With respect to the web,
there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the namespace tree.

Work such as DMARC (draft-kucherawy-dmarc-base), will certainly benefit
from having this capability.