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

[Jothan Frakes <[e-mail]>]

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: [phone]


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

> 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
>
> > 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?
>>
>
> 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.
>
> > 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?
>>
>
> The fact that they are both private--probably needs a parenthetical to
> this effect.
>
>
>> >    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
>>
>>
> This is probably simplistic, and more language from RFC 6265 sections 5.3
> and 5.4 should probably be integrated.
>
>
>> >    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.
>>
>>
> scope != policy domain
>
>
>> >    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 ?
>>
>
> If you have a better reference, I'm happy to substitute.  The use cases
> are more valuable the more specific they are.
>
>
>> > Authorities do not (knowingly) issue certificates for
>> >    public domain names such as *.org.au.
>>
>> 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.
>
>
>> >    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 intent of the carefully-worded statement above is not to support or
> refute the statement from RFC 6265, but simply to reference it.
>
> >    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
>> >    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
>>
>
> 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.
>
>
>> >    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
>>
>
> Could you please be more specific?
>
> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>
>