Re: [dbound] Updated draft-levine-orgboundary-03

[Casey Deccio <[e-mail]>]

Hi John,

On Wed, Nov 11, 2015 at 9:11 PM, John Levine <[e-mail]> wrote:

> Not to toot my own horn or anything, but I really think this does most
> of what people have said they want DBOUND to do, published in the DNS,
> with each domain publishing its own info in the tree it controls, no
> new TLDs or other administratively painful changes, provision for
> different boundaries for different applications, and most checks in
> one or two DNS queries regardless of how deep the name tree is.
>
> What's not to like?
>
>

I've given the draft a detailed read.  In general, the approach is
admittedly very similar to that in
draft-deccio-dbound-organizational-domain-policy (ODUP)  Some differences
are a matter of preference, and others have more technical implications.

- Both drafts use "opt-out" models.

- Terminology concerns (nits):
  - Boundaries vs. policies: both drafts mention boundaries and policies.
While there are similarities, and in particular, policies often utilize
boundaries, they aren't one and the same.  Yet that they seem to be
portrayed as such in the draft.
  - "Organization" (e.g., "belongs to the same organization").  The way I
understand the understand "organization" doesn't coincide with how it is
used in this draft.  I don't think of an organizational boundary as
something associated with a service or policy.  For example, I don't see
how a cookie policy changes the organizational boundary between two
domains.  I see "policy boundary" on occasion.  Perhaps the two simply need
to be reconciled.

- Lookup process - the process is very similar to that in ODUP.  Some
similarities and differences follow:
  - They both have iteration-stopping mechanisms (NXDOMAIN for ODUP;
NOLOWER for the current draft).
  - The current draft begins queries at the TLD, rather than at the root
(well, the _odup TLD anyway).
  - The current draft uses the entire DNS name (plus the _bound label) to
create the qname to be queried; in ODUP, each label is considered
separately.  There are revealing components to both (discussed on the ODUP
draft and in other email threads), but the latter is the more conservative
approach.
  - There is no "default" policy behavior in the current draft; the default
policy behavior in ODUP is current behavior.
  - There is no mechanism for offline lookup in the current draft,
contrasted with the ability to download policy realms (including the
policy-negative realm and other high-profile realms) for local use in the
ODUP draft.
  - Because one record for each service/policy is required, there are
potentially n*m lookups.  So while the performance is O(n) for any given
service, it is O(n*m) for all services/policies.  Some applications would
require understanding of multiple policies.  Contrast this with a hard O(n)
with ODUP, which has a consolidated service list.

- The following is a confusing sentence for "boundary node":
 "the one above the closest node to the root that also belongs to the same
organization as the input domain name."
It is somewhat clarified by the sentence immediately after, but the
qualifiers in the sentence itself are ambiguous.

- Why the use of wildcards?  The time complexity doesn't improve with
this.  It just seems like added complexity, so you can query for the entire
name, rather than label-by-label.  But as, mentioned previously, this is
revealing to higher level DNS authorities.

- What would be the road map to deploy this "now", given existing
application behavior?  This was one of the big reasons for the design of
ODUP: to provide a mechanism that is backwards compatible with existing
behaviors and has a transition path for expansion, with the idea that it is
technically capable of going "now".

Cheers,
Casey