Re: [Dbound] Draft problem statement and IETF "bar BoF"

[Edward Lewis <[e-mail]>]

Update - I did some fact checking and found that I am wrong about this:

"And E.g., compare how dotUK has been run (until the
recent policy change) versus CO.UK.  dotUK is essentially private (and
signed with NSEC to boot) but CO.UK. would be public.”

UK isn’t ‘NSEC' signed and I couldn’t find that it ever was.  I thought it
was, but I am wrong.

-----Original Message-----
From: Edward Lewis <[e-mail]>
Date: Wednesday, November 5, 2014 at 9:21
To: "[e-mail]" <[e-mail]>
Cc: Casey Deccio <[e-mail]>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>Instead of being specific, I’ll offer a general set of comments.  I think
>Casey and John have captured the state of the group, no argument with
>that, so my observations are about where we are and not the specifics in
>the paper.
>
>Perhaps a mistake we are making is talking (so much) about the DNS
>perspective.  Coming from the remark that zone cuts were avoided because
>we are ruling out zone cut identification as a goal: first, I agree this
>isn’t about zone cut identification.  But once we start analyzing the DNS
>side of this, we need to be accurate and faithful to the DNS architecture
>or we will screw this up - as in how one application screwed up an
>understanding of how DNS wild cards work resulting in a mismatch in what
>‘match’ means.  (I should cite the specific instance, it has been
>mentioned on the list, but I just can’t find it now.)  That said, I’d
>rather see the group “ignore” the DNS for the moment and concentrate on
>what “service” needs to be defined.
>
>I’m willing to go as far as recognizing that there are identifiers in play
>represented as domain names.  Beyond that, such as the fact that they are
>hierarchical and rendered in a format that makes them look more like a
>route than a name, isn’t that important.  In fact I think the paper spends
>a lot of words describing this and then saying this isn’t what is
>important.  IMHO, it comes to taking two identifiers (represented as
>domain names) and deciding if, for some operation they are to be
>considered the same/treated equally, or (I’ll say it again) equivalent.
>
>The material related to PSL falls into the same boat.  The PSL is a first
>stab at solving some part of the still somewhat hazy problem.  It is the
>crutch used to handle the first use case - the so-called cookies problem,
>better known (again, in my opinion) as the common origin problem.  The PSL
>and the DNS here are more “lay of the land” than part of the problem
>statement.  These are two things we have to work with, like unfinished and
>unset modeling clay.
>
>Because of that, take my comments before with a grain of salt.  Perhaps we
>need to go up a level and not down a level (as I was drilling into).
>
>But on to the discussion of whether upper level domains are exculsive-or
>public or private.  The problem I have is that in making such a divide (or
>any exclusive-or divide) if there are corner cases you’ll pay for it
>later.  I’m not sold that one can cleanly divide the domains, if so,
>whether it is meaningful - and I wretch in my seat because these are
>really zones, not domains.  E.g., dotUS is a mix of delegations and data.
>Perhaps you can call US public (for the most part it is), but it has some
>private elements.  And E.g., compare how dotUK has been run (until the
>recent policy change) versus CO.UK.  dotUK is essentially private (and
>signed with NSEC to boot) but CO.UK. would be public.
>
>I guess what I’m saying is that I’m not so clear on why we are labeling
>domains as public or private.
>
>Looking forward to getting to a problem statement.  And I do believe that
>there may be more than one problem to solve, which is why we seem to be
>going (if that can be said) in circles.
>
>-----Original Message-----
>From: Casey Deccio <[e-mail]>
>Date: Tuesday, November 4, 2014 at 16:18
>To: Edward Lewis <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>
>Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"
>
>>Hi Ed,
>>
>>On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis
>><[e-mail]> wrote:
>>
>>Thanks for writing this up. Now for the complaints. ;)
>>
>>
>>
>>
>>:)
>> 
>>
>>
>>You lost me at the first sentence of 1.1.1.  (Saying that more
>>dramatically than I mean to.)
>>
>>I don’t have a complete response to the paper.  In the spirit that
>>provoking thoughts is better than not at this point, here are some:
>>
>>Fragment 1
>>
>>I once believed that domain names were “dot-separated alphanumeric words”
>>but learned otherwise while working on the so-labeled clarifications on
>>wild cards.  In order to being to understand how the DNS organism is
>>architected, one has to view this as a tree.  And, ironically as I deal
>>increasingly with non-ASCII identifiers, there’s no dot "on the wire.”
>>(The root zone isn’t ‘.’, it’s a zero-valued byte.)
>>
>>
>>
>>
>>Good point.  The introduction in this document was to provide consistent
>>terminology sufficient to derive a model for understanding relationships
>>between domain names.  There is no talk of wire format, nor is there a
>>need to go into those semantics, as
>> this is all about namespace.  The representation in this document is
>>dot-separated labels. :)
>> 
>>
>>
>>
>>In section 1.1.2 an overly simplified view is given.  Not all domains fit
>>neatly into the public and private bucket.  Some top-level-domains are
>>not
>>delegation only.
>>
>>
>>
>>
>>
>>For clarity, are you saying that for a single domain being public and
>>private are not mutually exclusive, or are you saying that top-level
>>domains are not all public?  I agree with the latter statement, and I'm
>>glad to offer more clarity in the document
>> if it is misleading in this regard.
>>
>> 
>>
>>From these two comments my mind leads instantly into recommending that
>>this paper attempt to describe the problem from two very different
>>viewpoints.
>>
>>From the “system-to-be-messed-with” viewpoint, the nature of the DNS data
>>model as being first based on a tree structure must be respected as well
>>as a clear description of the management model based on the units of
>>zones.  The DNS protocol permits management of resource record sets,
>>domain (nodes) as well as zones but does not permit management of a
>>domain
>>(subtree).  (By the latter, I mean that DNS does not manage ‘across' a
>>zone cut.)
>>
>>
>>
>>
>>This is a valid point.  In this document I deliberately left zone cuts
>>out of the definitions.  The focus was on the problem of associating
>>namespaces, independent of zones.  Zone cut identification might be one
>>of the solutions considered, but even public/private
>> boundaries need not map consistently with zone cuts (in either
>>direction), so the problem is about namespace.
>>
>>
>>
>>
>>From the “people-having-a-problem-to-solve” viewpoint, which you get to
>>in
>>1.1.3 and 1.1.4, I prefer replacing “related” with “equivalent” for a
>>specific purpose.  (I’ve said that before, no need to belabor it now.)
>>For one, you talk about a parent/child relationship but there’s really no
>>such thing as that.  A parent delegates the child, the child knows
>>nothing
>>about it’s parent - there’s no “relationship” as far as the DNS protocol
>>is concerned.
>>
>>
>>
>>
>>Yes - but let's be clear that I'm establishing terminology for discussion
>>of namespace (not DNS protocol) for the purposes of this document.
>> 
>>
>>
>>
>>Without giving this much thought, cross-domain relationships have been
>>historically significant, more so in operations than in the protocol.
>>The
>>co-mingling of dotCom and dotNet bear this out.
>>
>>I’m concerned about the problem set-up because, your chances of solving
>>the problem are better if you’ve properly set up the problem.
>>
>>
>>
>>
>>Agreed.
>> 
>>
>>
>>
>>Fragment 2
>>
>>What’s missing from the PSL is a discussion of the registry behind the
>>PSL.  Looking strictly at the list of entries and concluding we just need
>>to make that work better is like saying a domain name registry is just a
>>DNS operator. I.e., how can you trust that the entries are legitimate?
>>
>>
>>
>>I can't tell if this is a general comment or something specific to the
>>document.  The problem statement document is not intended to assess the
>>content of the PSL--except to indicate the application of the model
>>described in previous sections in the paper (e.g.,
>> third paragraph of section 3).  The intent of the document is to define
>>the problem and identify existing solutions.  I make no conclusions.  The
>>question about the effectiveness of the PSL is partially addressed with
>>the second bullet under "problem statement"
>> in section 4.
>>
>>
>>
>>
>>Fragment 3
>>
>>This is not related directly to the document, but comes from “Centralized
>>vs. Distributed…”  One of the issues to think of is - how do we avoid
>>shared fate when we are looking for a new angle?  I.e., the DNS
>>distribution model is great for doing just what the PSL wants, but
>>placing
>>the PSL into the DNS is not helping.  Grossly arguing this way - if we
>>expect someone to try to register a child and use it to fool people using
>>the parent, what’s to stop the child from giving out fraudulent
>>information?  (This is a handwaving argument for why
>>what-ever-replaces-PSL should have some kind of separation from the DNS.)
>>
>>On the one hand, following the DNS tree is the best way to track who
>>knows
>>where the boundaries are.  On the other hand, that’s just the DNS
>>perspective talking.  And with only one source working here, we aren’t
>>making corrupting the system any harder than doing nothing at all.
>>
>>(I’m assuming that all of this is rooted in a security concern related to
>>the authorization of some information to be applied/accessed/etc.
>>Therefore, the talk about corrupting, fooling, fraudulent...)
>>
>>
>>
>>
>>
>>The scope of the problem statement is just that--a statement of the
>>problem.  These are valid considerations for solutions to the problem,
>>once the problem has been identified and defined.
>>
>> 
>>
>>Fragment 4
>>
>>It’s possible that here are multiple goals here, with a common theme not
>>clearly defined.  I see a desire to express the policies for a zone (not
>>a
>>domain) from the registry to a relying party.  This is one use case, not
>>the only, but one use case.  This is also expressed in a DNS viewpoint.
>>
>>The relying party applications I can’t speak as well for.
>>
>>Fragment 5
>>
>>I’m concerned about the mention of the gTLDs as being either “too much
>>detail” or “not enough detail.”  The “new class” of TLDs is only special
>>in two respects - the rapidity that they appear and that they share a set
>>of operating principles.  If by grouping them you default to grouping
>>ccTLDs and legacy gTLDs, you haven’t made a useful categorization.  Until
>>we know what criteria we will use to divide the top-level domains, we
>>should hold off on this.
>>
>>
>>
>>
>>
>>
>>
>>It is admittedly brief and can be fleshed out, if it needs clarity.  The
>>intent was not to give a discourse on the new gTLDs or to make a grouping
>>or categorization, but simply recognize that as gTLDs: 1) they fall into
>>the "unbroken public scope from
>> the TLD" category and thus are pertinent to the discussion of the
>>problem (and solutions, including the PSL); 2) the total number of gTLDs
>>has (and will continue to) increased dramatically with the delegation of
>>the new gTLDs; and 3) their policies vary, just
>> as with previous gTLDs.  There are thus open questions of both
>>complexity and scalability that should be considered as the problem is
>>defined and solutions identified.
>>
>>
>>Cheers,
>>
>>Casey
>>
>>
>>
>>
>>