Subject: [dbound] comments on draft-deccio-domain-name-relationships-00

From: =JeffH <[email-masked]>
Date: Mon, 23 Mar 2015 09:53:21 -0700

overall, I am curious about the focus on "public" vs "private" in 
draft-deccio-domain-name-relationships-00, and how the latter doc might 
relate to draft-sullivan-dbound-problem-statement-00 [0] ?

it seems to me that, as described in [0], the deployed actuality is that 
there is a multitude of policy variations between domain name registries..

    A particularly important distinction for security purposes is the one
    between names that are mostly used to contain other domains, as
    compared to those that are mostly used to operate services.  The
    former are often "delegation-centric" domains, delegating parts of
    their name space to others, and are frequently called "public suffix"
    domains or "effective TLDs".  The term "public suffix" comes from a
    site, [publicsuffix.org], that publishes a list of domains -- which
    is also known as the "effective TLD (eTLD) list", and henceforth in
    this specification as the "public suffix list" -- that are used to
    contain other domains.  Not all, but most, delegation-centric domains
    are public suffix domains; and not all public suffix domains need to
    do DNS delegation, although most of them do.  The reason for the
    public suffix list is to make the distinction between names that must
    never be treated as being in the same policy realm as another, and
    those that might be so treated.  For instance, if "com" is on the
    public suffix list, that means that "example.com" lies in a policy
    realm distinct from that of com.

..and that the above description succinctly captures such nuances, as well 
as defining the more generic term "policy realm", and that the coarse 
distinction of "public" vs "private" doesn't sufficently reflect the overall 
nuances of deployed reality.

my stream-of-consciousness-while-on-a-plane comments on 
draft-deccio-domain-name-relationships-00 are below, fyi/fwiw, but the above 
is my overall takeaway.

i hope this is helpful,

=JeffH

[0] http://tools.ietf.org/html/draft-sullivan-dbound-problem-statement-00

[1] http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01

 > Internet Engineering Task Force                                C. Deccio
 > Internet-Draft                                             Verisign Labs
 > Intended status: Informational                                 J. Levine
 > Expires: September 10, 2015                         Taughannock Networks
 >                                                            March 9, 2015
 >
 >
 >                  Concepts for Domain Name Relationships
 >                draft-deccio-domain-name-relationships-00
 >
 > Abstract
 >
 >    Various Internet protocols and applications require some mechanism
 >    for identifying relationships between Domain Name System (DNS) names.
 >    In this document we provide examples of protocols and applications
 >    for which knowledge of these relationships is useful, if not
 >    required.  Further we discuss the various types of domain name
 >    relationships, review current needs and solutions, and identify
 >    considerations for solution sets.
 >
 >
 > Table of Contents
 >
 >    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 >    2.  Domain Name Concepts . . . . . . . . . . . . . . . . . . . . .  3
 >      2.1.  Domain Names . . . . . . . . . . . . . . . . . . . . . . .  3
 >      2.2.  Domain Name Scope  . . . . . . . . . . . . . . . . . . . .  4
 >        2.2.1.  Public/private Boundaries  . . . . . . . . . . . . . .  4
 >      2.3.  Domain Name Relationships  . . . . . . . . . . . . . . . .  4
 >    3.  Policy-based Domain Name Relationships . . . . . . . . . . . .  5
 >      3.1.  Cross-Scope Policy Relationships . . . . . . . . . . . . .  5
 >      3.2.  Intra-Scope Policy Relationships . . . . . . . . . . . . .  5
 >        3.2.1.  Public-public Policy Relationships . . . . . . . . . .  6
 >        3.2.2.  Private-private Policy Relationships . . . . . . . . .  6
 >    4.  Known Applications Requiring Identification of
 >        Policy-based Domain Relationships  . . . . . . . . . . . . . .  6
 >      4.1.  HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . .  6
 >      4.2.  Email sender verification  . . . . . . . . . . . . . . . .  7
 >      4.3.  SSL certificate requests . . . . . . . . . . . . . . . . .  7
 >    5.  Public Suffix List . . . . . . . . . . . . . . . . . . . . . .  8
 >      5.1.  Known Application Usage  . . . . . . . . . . . . . . . . .  9
 >    6.  Solution Considerations  . . . . . . . . . . . . . . . . . . .  9
 >    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
 >    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 >    9.  Informative References . . . . . . . . . . . . . . . . . . . . 11
 >    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
 >
 >
 >
 > 1.  Introduction
 >
 >    The use of various Internet protocols and applications has introduced
 >    the desire and need for designated relationships between Domain Name
 >    System (DNS) names, beyond the lineal relationship inherent in the
 >    names themselves.  While protocols, such as that used by HTTP
 >    Cookies, have traditionally used ancestral relationships to determine
 >    allowable scope of information sharing and authorization, there is an
 >    increasing need to identify relationships between arbitrary domains.
 >
 >    We begin by establishing terminology and concepts, after which we
 >    discuss known applications for which the identification of domain
 >    name relationships are desirable or required.  We then discuss the
 >    Public Suffix List, the primary solution for domain relationships
 >    currently available.  Finally, we recommend considerations for
 >    solutions in this problem space.
 >
 >
 > 2.  Domain Name Concepts
 >
 >    For consistency in language we define terms and concepts surrounding
 >    domain names.
 >
 > 2.1.  Domain Names
 >
 >    A DNS domain name is represented as sequence of dot-separated labels,
 >    such as www.example.com (i.e., comprised of labels "www", "example",
 >    and "com").  This sequence corresponds to the list of the labels
 >    formed by traversing the tree representing the domain name space,
 >    from the node representing the name itself to the root (top) of the
 >    tree ([RFC1034]).  In this tree context, we thus refer to domain
 >    name's parent as the domain name formed by removing the leftmost
 >    label (i.e., the domain name corresponding to the node directly above
 >    it in the tree).  The parent of www.example.com is example.com.
 >
 >    As there are no requirements or inferences surrounding delegation
 >    (i.e., zone cut) at any point in the DNS tree, there are no
 >    assumptions in this document about administrative boundaries drawn by
 >    delegations, unless explicitly stated otherwise.  That is to say that
 >    this document considers DNS names independently from their
 >    administration, as defined by the DNS.

suggest:

    That is to say: this document considers DNS names independently
    from their DNS-specific technical administration.

 >    As noted in [RFC1034], the term "domain name" is used in contexts
 >    outside the DNS.  The scope of this document is limited to domain
 >    names as defined by the DNS.

aside: is there an RFC for "the DNS" that is equivalent to, say, RFC3377 
(which defined the LDAPv3 spec set) ?

 > 2.2.  Domain Name Scope
 >
 >    The use of domain names in various applications over time has
 >    produced a notion of scope, which we use to refer to the general
 >    ability of arbitrary entities to register children of a domain name
 >    (i.e., create child nodes in the domain name tree).  In some contexts
 >    these are called "public suffixes" or "registry controlled domains"

s/contexts/contexts,/

s/called/referred to as/

 >    ([RFC6265]).  For example, children of the top-level domain (TLD)
 >    com, are generally registrable by arbitrary entities, which puts the
 >    com domain name in the public scope.  However, com's children are
 >    typically not used in the same fashion (though certainly there are
 >    exceptions), which puts them largely in the private scope.

need more thoroughly defined notion  of public & private because there are 
so many shades of grey in between them -- the diff is actually more which 
registry controls particular portions of the namespace, its policies, and 
who administers it aka "policy authority {realm,domain,range,scope,..}"

i.e., declaring this particular scope dimension as simply public or private 
is too coarse grained and potentially misleading

   domain registry scope == policy realm    (see [1])

 >
 >    The children of public domain names may either be in public or
 >    private scope; likewise the children of private domain names may
 >    either be in public or private scope.

suggest:

    The children of names in one policy realm may either be
    within the same policy realm or a different policy realm.

"scope" seems to be essentially be used as "policy realm" [1]

 >
 >    While zone cuts often exist along public/private scope boundaries
 >    (e.g., between com and example.com), they are not required at these
 >    boundaries, nor are scope boundaries required at zone cuts.

suggest:

    While zone cuts often exist along policy realm boundaries (e.g., between
    com and example.com), they are not required at these boundaries, nor are
    policy realm boundaries required at zone cuts.

 >                                                           In this
 >    document public/private scope is considered independent of
 >    administrative boundaries defined by the DNS (i.e., zone cuts).

suggest:

    In this document, policy realm boundary extent is considered
    independent of DNS technical administration (e.g., zone cuts).

 >
 >    The most well-known delineator of public/private scope is the Public
 >    Suffix List (PSL) [PSL], which is described later in this document.

It is quite unfortunate that the term "effective TLD" was supplanted by 
"public suffix" -- and even effective TLD is too coarse of a term for what 
it effectively represents

 > 2.2.1.  Public/private Boundaries
 >
 >    If we consider the root domain name itself to be public, then between
 >    the root domain name and any private domain name (below), there must
 >    exist at least one boundary going from some public parent to private
 >    child.  The first such boundary encountered upon downward traversal
 >    from the root is the first-level public boundary.  Subsequent public-
 >    to-private boundaries are referred to as lower-level public
 >    boundaries.  For example, because the com domain name is considered
 >    public, if we assume that example.com is private, then the first-
 >    level public boundary is between com and example.com.  If the
 >    public.example.com domain name is considered public (i.e., children
 >    domain names can be registered by arbitrary third parties) and
 >    foo.public.example.com is a private domain name, then a lower-level
 >    public boundary exists between public.example.com and
 >    foo.public.example.com.

having discussion of the fact as one traverses the DNS tree, one will 
traverse policy realm boundaries is useful

using the "public" vs "private" coarse distinction is however, misleading 
and seriously glosses over the necessary-to-understand nuance that there can 
be very fine-grained yet distinct and important differences between the 
registry policies of one policy realm to another policy realm

yes, anyone may /attempt/ to register a label directly under the root, hence 
it might seem "public", but doing so is strictly controlled by a large and 
complex set of policies administered by ICANN, and one is not guaranteed to 
pass muster and have their desired name (and associated namespace management 
policies) accepted by ICANN -- thus simply referring to the namespace one 
level below the root as just a "policy realm" is more generic and the term 
can be used to refer to any policy/governance/registry boundary anywhere in 
the dns namespace (aka tree).

 >
 > 2.3.  Domain Name Relationships
 >
 >    In this document two types of domain name relationships are
 >    identified: ancestry and policy.  An ancestral relationship exists
 >    between two domains if one domain name is an ancestor of the other.

why introduce yet another term ie "ancestor" ?   above, the terminology is 
parent / child

 >
 >
 >    A policy relationship exists between two domain names if their
 >    relationship is such that application policy should treat them as
 >    equivalent.  For example, the two names might be administered by the
 >    operating organization, or there might business or other
 >    relationships between the two operating entities.

clean up above

 >
 >    In the simplest case, two domain names might be policy-related for
 >    all applications or purposes.  However, it is possible that two
 >    domains are related only for explicitly defined purposes.
 >
 >    An ancestral relationship between two names can be identified merely
 >    by comparing the names themselves to determine whether one is a
 >    substring of the other.  However, there is no inherent way to
 >    determine policy relationships neither by examination of the names
 >    themselves, nor by examining the administrative boundaries (i.e.,
 >    zone cuts) defined in the DNS.  This is the problem being considered
 >    in this document.

clean up above

 > 3.  Policy-based Domain Name Relationships
 >
 >    Because policy-based domain name relationships are not inherently
 >    apparent based on the names themselves or DNS protocol, mechanisms
 >    outside the DNS namespace and base protocol are necessary to
 >    advertise and detect those relationships.

??

 >
 >    In this section we enumerate the different types of ancestral and
 >    scope relationships upon which policy-based relationships can be
 >    overlaid.
 >
 > 3.1.  Cross-Scope Policy Relationships
 >
 >    If scope of one domain name is public and another is private, then it
 >    can be inferred, by the definition of their respective scopes, that
 >    there exists no policy-based relationship between the two.  That is,
 >    a public domain name cannot be related, for policy purposes, to a
 >    private domain name.
 >
 >    Note that this doesn't prohibit policy relationships between two
 >    domain names of the same scope but having (an even number) of scope
 >    boundaries in between.

public/private is too coarse-grained

 >
 > 3.2.  Intra-Scope Policy Relationships
 >
 >    We now consider the existence of a policy relationship between two
 >    domains names of the same scope.
 >
 >
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015               [Page 5]
 > 
 > Internet-Draft   Concepts for Domain Name Relationships       March 2015
 >
 >
 > 3.2.1.  Public-public Policy Relationships
 >
 >    The connotation of a public domain name in the context of policy is
 >    that it should not be used for purposes normally associated with
 >    private domain names.  For example, it would be unreasonable to
 >    expect legitimate mail to come from an email address having the exact
 >    suffix of org.au (a domain name currently identified by [PSL] as
 >    being public).  This is especially true of domain names above the
 >    first-level public boundary.

why?  could not the administrators of a particular policy realm, even a 
single-label one, cause email (eg theirs) to be sent "from" an address at 
that single-label policy realm?

also are not single-label domains emerging in real fact?

 >
 >    Because of this connotation, one consideration for policy amongst two
 >    domain names, both public, is that no effective relationship exists
 >    because they are ineligible by definition.  Other than that, there is
 >    insufficient information from only domain names and scope alone to
 >    confirm or deny a policy relationship.
 >
 > 3.2.2.  Private-private Policy Relationships
 >
 >    There are two classes of potential private-private policy
 >    relationships: ancestral and cross-domain (non-ancestral).  In
 >    neither case can the presence or absence of a policy relationship be
 >    confirmed using only the names and scope information.

what scope information?

 >
 >
 > 4.  Known Applications Requiring Identification of Policy-based Domain
 >     Relationships
 >
 >    In this section we discuss the current state of known applications
 >    requiring identification of policy-based domain name relationships.
 >
 > 4.1.  HTTP Cookies
 >
 >    Domain names are used extensively in conjunction with the Hypertext
 >    Transfer Protocol (HTTP) ([RFC7230], [RFC7231]).  The domain names
 >    used in Uniform Resource Identifiers (URIs) [RFC3986] are used by
 >    HTTP clients not only for resolution to an HTTP server Internet
 >    Protocol (IP) address, but also for enforcing policy.
 >
 >    HTTP clients maintain local state in the form of key/value pairs

s/local state/application state/

establishing such state is directed by the server

 >    known as cookies ([RFC6265]).  While most often cookies are initially
 >    set by HTTP servers, HTTP clients send all cookies in HTTP requests
 >    for which the domain name in the URI is within the cookies' scope.
 >    The scope of a cookie is defined using a domain name in the "domain"
 >    attribute of the cookie.  When a cookie's "domain" attribute is
 >    specified as a domain name (as opposed to an IP address), the domain
 >    name in the URL is considered within scope if it is a descendant of
 >    the "domain" attribute.

hm need to check 6265

 >    RFC 2965 [RFC2965] (now obsolete) required that the value of the
 >    "domain" field carry at least one embedded dot.  This was to prohibit
 >    TLDs--which were almost exclusively public--from being associated, by
 >    policy, with other domains.  Cookies having public scope would enable
 >    the association of HTTP requests across different, independently
 >    operated domains, which policy association raises concerns of user
 >    privacy and security.
 >
 >    In the current specification ([RFC6265]), the semantic requirements
 >    were modified to match "public suffixes" because it was recognized
 >    that TLDs are not the only domain names with public scope--and that
 >    not all TLDs are public suffixes.  The notion that all TLDs are
 >    inherently public has been challenged by the many and diverse domain
 >    names that have been delegated since 2013 as part of the new generic
 >    top-level domain (gTLD) program ([NewgTLDs]).

the latter is correct, tho am not sure of reason to explain this distinction 
in this way.  the latter paragraph illustrates the more fine-grained 
distinctions between policy realms rather than using the coarse terms 
public/private.

 >
 > 4.2.  Email sender verification
 >
 >    An emerging sender verification called Domain-based Message

s/sender/email sender/

 >    Authentication, Reporting and Conformance (DMARC)
 >    [I-D.kucherawy-dmarc-base] attempts to validate the domain name of
 >    the author's address on the message's "From:" header using the
 >    DomainKeys Identified Email (DKIM) [RFC5585] and Sender Policy
 >    Framework (SPF) [RFC7208] authentication schemes.  A DKIM signature
 >    and SPF check each validate a specific domain name.  For DKIM it is
 >    the domain name corresponding the DKIM signature.  For SPF the domain
 >    name of the message's bounce address is validated.  DMARC allows
 >    approximate matching between the author's domain and the validated
 >    domain name, where one can be an ancestor or descendant of the other.
 >
 >    DMARC validators are supposed to ensure that the two domain names are
 >    under the same management, the specifics of which are deliberately
 >    left out of the spec.

thus having a need for discerning policy realms

 >
 > 4.3.  SSL certificate requests

s|SSL|TLS/SSL| globally

 >
 >    Secure Socket Layer (SSL) certificate authorities typically validate
 >    certificate signing requests by sending a confirmation message to one
 >    of the WHOIS contacts for the (private scope) domain name (CA/B
 >    Ballot 74 [CA/B-Ballot-74]).

referencing a ballot in a non-open org?  why not the BRs ?

 >                                   In cases where there are multiple
 >    levels of delegation (i.e., crossing public/private scopes), the
 >    WHOIS contact needs to be the one for the registrant of the domain,
 >    not a higher level registration.
 >
 >    When an SSL certificate is for a wildcard domain name, the entire
 >    range of names covered by the wildcard needs to be under the same
 >    control.

..and thus having a means to ascertain this would be useful

 > Authorities do not (knowingly) issue certificates for
 >    public domain names such as *.org.au.

what is the distinction/implication of the latter name?

 >
 > 5.  Public Suffix List
 >
 >    The most well-known resource currently available for identifying
 >    public domain names is the Public Suffix List (PSL) [PSL].  The PSL
 >    is explicitly referenced as an example of an up-to-date public suffix
 >    list in [RFC6265].

well, more or less up-to-date

 > The PSL was developed by Mozilla Firefox
 >    developers to further address HTTP security and privacy concerns
 >    surrounding cookie scope when the "no embedded dot" rule of [RFC2965]
 >    was the upper limit.
 >
 >    The PSL contains a list of known public suffixes, and includes
 >    placeholder public domains designated by "wildcard" notation in the
 >    file.  A wildcard implies that all children of the wildcard's parent
 >    are in fact public domain names themselves--except where otherwise
 >    noted as a wildcard exception.  For example, we use the contrived
 >    entries in Table 1 to demonstrate this use of the PSL.
 >
 >            +--------------+------------------------------------+
 >            | Entry        | Meaning                            |
 >            +--------------+------------------------------------+
 >            | example      | example is public                  |
 >            | *.example    | All children of example are public |
 >            | !foo.example | foo.example is private             |
 >            +--------------+------------------------------------+
 >
 >                       Table 1: Contrived PSL Entries
 >
 >    These entries result in the scopes shown in Table 2:
 >
 >                      +---------------------+---------+
 >                      | Name                | Scope   |
 >                      +---------------------+---------+
 >                      | example             | Public  |
 >                      | foo.example         | Private |
 >                      | baz.foo.example     | Private |
 >                      | bar.example         | Public  |
 >                      | baz.bar.example     | Private |
 >                      | www.baz.bar.example | Private |
 >                      +---------------------+---------+
 >
 >          Domain name scope based on the PSL entries from Table 1.
 >
 >                       Table 2: Contrived PSL Entries
 >
 >    The PSL effectively identifies scope, insomuch as the list is

s/scope/policy authority realm boundaries/

 >    accurate.  Of the 6,823 entries in the PSL at the time of this
 >    writing, all but 50 are used to designate first-level public
 >    boundaries; the remainder designate lower-level boundaries.  The
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015               [Page 8]
 > 
 > Internet-Draft   Concepts for Domain Name Relationships       March 2015
 >
 >
 >    primary function of the PSL, therefore, is to delineate first-level
 >    public boundaries.

uh, but that's "today" -- it will evolve as the DNS namespace evolves

 >
 >    Matters of policy that can be settled simply by identifying the scope
 >    of the names in question are thus addressed by the PSL.  However, the
 >    question of determining whether a policy-based relationship between
 >    intra-scope names (with the possible exception of those of public
 >    scope) are unaddressed.

too coarse

 >
 > 5.1.  Known Application Usage
 >
 >    The PSL is used by several browsers, including Mozilla Firefox, to
 >    identify domain names as public or private.  This is used for
 >    validating the domain attribute of cookies.  Additionally, it
 >    provides visual and organizational convenience for readily
 >    identifying the highest intra-scope private ancestor for a given
 >    private domain name (i.e., the child of the domain name's nearest
 >    public ancestor).  This is useful for organizing names and URIs by
 >    domain name, as in bookmarks, and for highlighting key parts of URIs
 >    or certificates in the address bar or other parts of the browser
 >    interface.
 >
 >    Existing DMARC implementations are known to use the PSL to assert
 >    policy-based relationships between SPF- or DKIM-authenticated
 >    validated domain names and domain name corresponding to the address
 >    in the "From:" header.  Such a relationship is identified if two
 >    domain names are both of private scope and share an ancestral
 >    relationship.
 >
 >    DMARC implementations also use the PSL to identify the highest intra-
 >    scope ancestor of a (private) domain name for the purpose of looking
 >    up the DMARC DNS record.  The the appropriate ancestor name is
 >    identified it is appended to the label "_dmarc" to find the
 >    appropriate information in the DNS.
 >
 >    SSL certificate authorities use the PSL to ensure that wildcards are
 >    not issued for domain names having public scope.
 >
 >
 > 6.  Solution Considerations
 >
 >    The problem discussed in this document is the association of domain
 >    names for policy purposes.  The PSL has been the de-facto
 >    supplementary resource utilized for identifying such relationships.
 >    The shortcomings of only having domain names and their scope (e.g.,
 >    via the PSL) have been treated in Section Section 5.
 >
 >    An alternate paradigm for addressing the problem involves a system
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015               [Page 9]
 > 
 > Internet-Draft   Concepts for Domain Name Relationships       March 2015
 >
 >
 >    wherein policy-based relationships are explicitly defined on a per-
 >    domain name (pair) basis.  For scalability and dynamic response this
 >    is most effectively achieved through defining these relationships in
 >    the DNS itself, e.g., through special records included in the DNS at
 >    (or near) the domain names themselves, such as the mechanism proposed
 >    in [I-D.sullivan-domain-origin-assert].

 >    One benefit to this paradigm
 >    is that it allows the definition of policy-based relationships
 >    between arbitrary names at any locations in the DNS domain name tree,
 >    and the notion of scope becomes moot.  Another benefit is that it
 >    puts the definition of those relationships in the hands of the
 >    administrators and operators of the domain names themselves, rather
 >    than a third party.
 >
 >    There are several challenges with the domain name-centric paradigm as
 >    well.  One challenge is that it requires correct, consistent, and
 >    coordinated efforts by affected domain name operators.  The number of
 >    involved parties, moving parts, and dependencies introduces more
 >    chance for error.  Additionally, having the information available
 >    online (e.g., in the DNS) means that consumption by local
 >    applications is dependent on real-time Internet connectivity, which
 >    is not always possible nor desirable.
 >
 >    Another solution set is that which includes both a scope definition
 >    resource (e.g., the PSL) and a mechanism for explicit definition of
 >    policy-based relationships on a per-domain name basis.  In this case
 >    the scope definitions are consulted first to determine whether a
 >    policy-based relationship is possible, after which (if necessary)
 >    special domain name-specific lookups are issued to further determine
 >    whether such a relationship exists.  This addresses what might be the
 >    most common issues using a central, relatively simple, and
 >    established mechanism, leaving the flexibility for additional
 >    extensibility with domain name-specific relationship definitions.
 >
 >    We recommend that the cost and the value of the different solution
 >    paradigms be considered when developing solutions for the problem of
 >    defining policy-based relationships between domain names.  As part of
 >    this, the model of domain name relationships outlined in Section
 >    Section 2.3 should be analyzed to consider which types of
 >    relationships are most in demand, and which solutions are sufficient
 >    for the circumstances in highest demand.  Such will enable an
 >    appropriate and usable balance of efficiency, robustness,
 >    flexibility, and autonomy.
 >
 >
 > 7.  IANA Considerations
 >
 >    This document includes no requests for IANA.
 >
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015              [Page 10]
 > 
 > Internet-Draft   Concepts for Domain Name Relationships       March 2015
 >
 >
 > 8.  Security Considerations
 >
 >    This document does not specify a protocol or usage and, therefore,
 >    there are no new security considerations for it.  There are security
 >    considerations for major cases in which domain boundaries are used,
 >    such as HTTP Cookies and DMARC, both discussed here.  See the
 >    Security Considerations of RFC 6265 [RFC6265] and
 >    [I-D.kucherawy-dmarc-base].
 >
 >
 > 9.  Informative References
 >
 >    [CA/B-Ballot-74]
 >               Certificate Authority(CA)/Browser Forum, "Ballot 74",
 >               2015, <https://cabforum.org/2012/05/31/
 >               ballot-74-updates-to-domain-and-ip-validation-high-risk-
 >               requests-and-data-source-in-the-baseline-requirements/>.
 >
 >    [I-D.kucherawy-dmarc-base]
 >               Kucherawy, M. and E. Zwicky, "Domain-based Message
 >               Authentication, Reporting and Conformance (DMARC)",
 >               draft-kucherawy-dmarc-base-13 (work in progress),
 >               February 2015.
 >
 >    [I-D.sullivan-domain-origin-assert]
 >               Sullivan, A., "Asserting DNS Administrative Boundaries
 >               Within DNS Zones", draft-sullivan-domain-origin-assert-02
 >               (work in progress), October 2012.
 >
 >    [NewgTLDs]
 >               ICANN, "New Generic Top-Level Domains", 2015,
 >               <http://newgtlds.icann.org/>.
 >
 >    [PSL]      Mozilla Foundation, "Public Suffix List", 2015,
 >               <https://publicsuffix.org/>.
 >
 >    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
 >               STD 13, RFC 1034, November 1987.
 >
 >    [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
 >               Mechanism", RFC 2965, October 2000.
 >
 >    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 >               Resource Identifier (URI): Generic Syntax", STD 66,
 >               RFC 3986, January 2005.
 >
 >    [RFC5585]  Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
 >               Identified Mail (DKIM) Service Overview", RFC 5585,
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015              [Page 11]
 > 
 > Internet-Draft   Concepts for Domain Name Relationships       March 2015
 >
 >
 >               July 2009.
 >
 >    [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
 >               April 2011.
 >
 >    [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
 >               Authorizing Use of Domains in Email, Version 1", RFC 7208,
 >               April 2014.
 >
 >    [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
 >               (HTTP/1.1): Message Syntax and Routing", RFC 7230,
 >               June 2014.
 >
 >    [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
 >               (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
 >
 >
 > Authors' Addresses
 >
 >    Casey Deccio
 >    Verisign Labs
 >    12061 Bluemont Way
 >    Reston, VA  20190
 >    USA
 >
 >    Phone: +1 703-948-3200
 >    Email: [email-masked]
 >
 >
 >    John Levine
 >    Taughannock Networks
 >    PO Box 727
 >    Trumansburg, NY  14886
 >
 >    Phone: +1 831 480 2300
 >    Email: [email-masked]
 >    URI:   http://jl.ly
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 > Deccio & Levine        Expires September 10, 2015              [Page 12]
 >

---

From: Casey Deccio <[email-masked]>
Date: Mon, 23 Mar 2015 15:58:31 -0400

Thanks for the comments.  Those not implicitly addressed by the
public/private scope commentary in the forked thread or otherwise
necessitating additional commentary are addressed below.

Thanks,
Casey

> that single-label policy realm?

Again - we're not talking about policy realms.  This is a discussion of
public-scoped names, which by definition, have certain distinction, in
terms of their use and constraints, from private names.

> also are not single-label domains emerging in real fact?

Note that I explicitly challenge the notion that a single label implies
public (or that public implies single-label, for that matter.

> >    confirmed using only the names and scope information.

The fact that they are both private--probably needs a parenthetical to this
effect.

> >    name in the URL is considered within scope if it is a descendant of
This is probably simplistic, and more language from RFC 6265 sections 5.3
and 5.4 should probably be integrated.

> the latter is correct, tho am not sure of reason to explain this
> distinction in this way.  the latter paragraph illustrates the more
> fine-grained distinctions between policy realms rather than using the
> coarse terms public/private.
>
>
scope != policy domain

> referencing a ballot in a non-open org?  why not the BRs ?

If you have a better reference, I'm happy to substitute.  The use cases are
more valuable the more specific they are.

> what is the distinction/implication of the latter name?
That it is a public name (as defined in the PSL) and is used earlier in the
document as an example of such.  I can use another parenthetical to remind
the reader of that.

> well, more or less up-to-date
The intent of the carefully-worded statement above is not to support or
refute the statement from RFC 6265, but simply to reference it.

> uh, but that's "today" -- it will evolve as the DNS namespace evolves

That's speculative, but 1) yes, the statement represents the primary
function of the PSL both currently (i.e., "today") and for the foreseeable
future; and 2)  its evolution would be based on the evolution of the *use*
of the DNS namespace.  Remember the distinction is about first-level vs.
lower-level boundary identification.

> >    intra-scope names (with the possible exception of those of public

Could you please be more specific?

---

From: Casey Deccio <[email-masked]>
Date: Tue, 24 Mar 2015 11:20:23 -0400

I noticed that the first part of my response was accidentally omitted from
the message that was actually sent, so I'm rewriting it here.

Casey

> (which defined the LDAPv3 spec set) ?
RFC 1034/1035?

> who administers it aka "policy authority {realm,domain,range,scope,..}"

Could you explain what you mean by shades of grey?  If it is grey, then it
must not be public.

See also the NOTE in bullet 5 of section 5.3 in RFC 6265.

> i.e., declaring this particular scope dimension as simply public or
> private is too coarse grained and potentially misleading
>

>   domain registry scope == policy realm    (see [1])

The draft distinguishes between scope and policy relationships, and there
is not an equivalence between the two.

> it effectively represents

There is a difference between what it *represents* and how it is being
*used*.  The PSL is a list defining suffixes known to be of public scope.
When used (exclusively) as the basis for policy, then it can in fact be too
coarse.

> and seriously glosses over the necessary-to-understand nuance that there
> can be very fine-grained yet distinct and important differences between the

Let me reiterate that scope is not equivalent to policy realm.

>
> yes, anyone may /attempt/ to register a label directly under the root,
> hence it might seem "public", but doing so is strictly controlled by a
> large and complex set of policies administered by ICANN, and one is not
> guaranteed to pass muster and have their desired name (and associated
> namespace management policies) accepted by ICANN -- thus simply referring
> to the namespace one level below the root as just a "policy realm" is more
> generic and the term can be used to refer to any policy/governance/registry
> boundary anywhere in the dns namespace (aka tree).
>

This is exactly why I make the case in the draft that namespace (including
TLDs) is independent from both scope and policy:

   ...there is no inherent way to
   determine policy relationships neither by examination of the names
   themselves, nor by examining the administrative boundaries (i.e.,
   zone cuts) defined in the DNS...

   top-level domain (gTLD) program ([NewgTLDs])....

> why introduce yet another term ie "ancestor" ?   above, the terminology is

Ancestor is a recursive parent.  It seemed to me that extending terminology
based on the "family tree" theme was intuitive.  However, I can define it
explicitly if that's not the case.

> >    relationships between the two operating entities.

Could you please be more specific about your concerns and/or supply a
wording to update the text?

> >    zone cuts) defined in the DNS.  This is the problem being considered

Could you please be more specific about your concerns and/or supply a
wording to update the text?

??

> public/private is too coarse-grained

This inferred property does not suggest an equivalence between policy and
scope boundaries, but rather that crossing scope boundaries indicates that
a policy relationship does not exist, by definition.

---

From: Jothan Frakes <[email-masked]>
Date: Tue, 24 Mar 2015 13:00:57 -0700

I won't be able to make it to Texas for the IETF meeting, but wanted to put
forth some input.

One observation that I have witnessed is that "Public / Private" has some
different context, depending upon the reader, and the use and application
of these terms.  I suspect that these contexts are blurring and confusing
things a tad.

There is a concept of those that have been delegated directly from
IANA/ICANN, and those that jump in at some point within that which are not
necessarily 'registries' (some are, some aren't) being Public and Private.

I think Casey and John have done a fair job of summarizing some of the
contexts of Public/Private within Casey's draft, yet one thing that is
possibly blurred between this and the IANA/ICANN direct relationships is
the concept of administrative transition.

I would not encourage that the PSL definitions of Public/Private sections
or comments about entries from within the PSL .dat file be used as any
frame of reference other than convenience.  The entries as submitted by
respective administrators should be used for context of how these
administrators wanted cookies to behave.  That's essentially it.  These are
two separate things, regardless of where they are in the file.

The cookie realm is different than the SSL Cert realm, is different from
the email realm, is different than the _____ realm.

Does the PSL get used for other things - absolutely.  And each potentially
has its own concept of 'Public'/'Private'.

As one of the PSL volunteers, I can share the approximate timing of and the
origin of 'Public' / 'Private' label in that context as it was introduced
in the Mozilla PSL as sections :
https://bugzilla.mozilla.org/show_bug.cgi?id=712640 and
https://bugzilla.mozilla.org/show_bug.cgi?id=681585

The split really surrounded an accommodation of a section for the new TLDs
rather than at the end of the file, to be a continuation of the ICANN/IANA
listings, in creation of a process to reasonably update the PSL at the pace
that the incredibly efficient contracting and operations teams in ICANN are
getting it done.

We could have just as easily named the sections "Bert" and "Ernie", or
"Wookies" and "Ewoks".  It just made more sense that these be read by third
parties to latch onto a conceptual context of what was being done.

The splitting of entries was literally for managing the ever-growing file,
and there was no policy determination made other than to try and make
reasonable best efforts to keep those directly assigned by IANA / ICANN
(respecting the ICP-3 root) and those not directly assigned (as
self-identified by the respective authority or community to the best
ability of the volunteers) "organized".

The objective has always been to ensure non-discriminatory inclusion of
things like  Amazon AWS, Centralnic subdomain registries or Github, DYN et
al.  I'll single out Centralnic as an example of a good actor in the
sub-domaining space.. from within the PSL - the bright line example that
comes to mind is EU.COM or COM.DE where they operate a registry and assign
names underneath these 'As If' they were a TLD.

One concern, if I could voice it, would be in inadvertently introducing
something that would make it possible for .COM to disallow US.COM or charge
additional fees for some special 'blessing' or right to innovate, while in
and of itself not inferring a 'blessing' that service through inclusion.
The PSL community is agnostic on the inclusion other than to make
reasonable efforts to validate the request came from the party
administratively responsible for the domain name in question, or the
operators of .DE could/would disallow or allow COM.DE by withholding some
administrative transfer record in the .DE zone (IF DNS is used for this).
Not for any commercial reason, but because of the incredible disruption it
would cause to the community of name holders.

The core focus of PSL is, from its origin, one of creating a solution to
aid in securing cookies from bleeding out to the wrong places.  The
derivative uses that have evolved since its creation have been amazing and
very indicative of a need for solution space, such as search engines,
browser 'omnibox' behavior, anti-spam, and the numerous development
community.

Candidly, (and I realize this additional and important color does not
necessarily put these terms into clean buckets) the concept of
public/private scope will absolutely change from circumstance of
application/use and depend upon that scope - these are different in DNS
than in EMAIL than in Cookies and varieties of Web activity.  Other
examples of derivative uses include UX/UI (form validation being an
example, wanting to exclude invalid entries), Security / Log Forensics
(need to have a clear indicia of subdomain vs domain ownership breakpoints,
to query a whois server, for example).  Each will have their own context
and scope for 'public' or 'private'.

I would encourage that where possible, there can be a scope included in
DBOUND efforts which contextually identify the usage, akin to how MX vs A
records work in DNS.

I'll repeat something that is frequently said within the community of
developers who like myself help maintain the PSL, PSL exists only because
nothing else did, and it is the least awful solution out there.

In the context of our DBOUND efforts, there would be a grateful transition
to something that does what it does or better, but it is likely that
something that does not, shall not be attractive enough to the base of
developers, libraries, and integrators to make the effort to pivot to
something else.

-Jothan

Jothan Frakes
Tel: +1.206-355-0230

On Mon, Mar 23, 2015 at 12:58 PM, Casey Deccio <[email-masked]> wrote:

> The fact that they are both private--probably needs a parenthetical to
> this effect.
>
>
> If you have a better reference, I'm happy to substitute.  The use cases
> are more valuable the more specific they are.
>
>
> That it is a public name (as defined in the PSL) and is used earlier in
> the document as an example of such.  I can use another parenthetical to
> remind the reader of that.
>
>
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>
>