Subject: [Int-dir] FYI - RE: WG Review: Domain Boundaries (dbound)

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Mar 2015 16:31:57 +0000

I had blocked this post as it wasn't clear it was intention, but IETF Secretary did indicate it was intentional as Barry wanted the Internet Directorate to be notified.

> -----Original Message-----
> From: The IESG [mailto:[email-masked]]
> Sent: Friday, March 06, 2015 7:41 PM
> To: IETF-Announce
> Cc: dbound WG; Internet Directorate
> Subject: WG Review: Domain Boundaries (dbound)
>
> 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 <[email-masked]>
>
> Mailing list
> Address: [email-masked]
> 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.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Mar 2015 12:38:09 -0400

> I had blocked this post as it wasn't clear it was intention, but IETF Secretary did indicate it was intentional as Barry wanted the Internet Directorate to be notified.

As a rule, if the IESG sends mail to a particular IETF mailing list, you should allow it through.   One assumes that the reason for passing it through was that it was hoped someone from int-dir would review the charter.   Might have been nice if Barry had specifically requested that, though, rather than leaving it to chance...   (Hi, Barry!)

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Mar 2015 12:40:43 -0400

> As a rule, if the IESG sends mail to a particular IETF mailing list, you
> should allow it through.   One assumes that the reason for passing it
> through was that it was hoped someone from int-dir would review the
> charter.   Might have been nice if Barry had specifically requested that,
> though, rather than leaving it to chance...   (Hi, Barry!)

I didn't leave it to chance: I asked the Secretariat to handle it.  They did.

Barry