Re: [dbound] The proposals before us

[Casey Deccio <[e-mail]>]

On Sat, Sep 3, 2016 at 4:57 PM, John Levine <[e-mail]> wrote:

> ODUP: first party publication with TXT records, can work but has a lot
> of stuff not useful for the mail application.


You mean it supports the addition of policy-defining directives in the
future?  Yup.  I don't think there's a lot of overhead there.


>   Number of queries
> varies but seems usually to be the number of components in the name.
>

Proper use of the "fetch" directive (introduced in version -01 and fleshed
out in version -02; the current version is -03 [1]) allows an application
to pull down ahead of time or on-demand the policy for an entire namespace
tree.  This is especially useful for 1) the "upper" domains, i.e., those
currently referred to as "public suffixes"; and 2) domains with heavy
usage.  Downloading the policy associated with public suffixes ahead of
time brings the number of DNS lookups for names in any domain with no
explicit policy (i.e., using default behavior) to one [2].  Downloading the
policy associated with other domains (especially those with heavy usage)
brings lookups to zero for names in those domains.

I envision two possible companion documents for ODUP: one to document best
practice application usage for fetching of policies using "fetch" (how
often to check, etc.); and one to document a mechanism for "advertising"
domains for which policy can/should be downloaded ahead of time.  Note that
the latter isn't supposed to be a PSL-like list that includes policy, but
simply a pointer to the domains that might want policy downloaded ahead of
time.

Mine: minimal design.  Number of queries is typically the number of
>
boundaries (not components) or that number plus 1, which in practice
> seems unlikely to be more than 2.


There are two major tradeoffs here:

1) Minimal information disclosure.  There is a broad effort to minimize
information disclosure in the name of privacy.  ODUP keeps with those
efforts by only disclosing the information necessary to find the policy or
next delegation of policy--sort of the qname-minimization equivalent of
DBOUND.  The Levine draft specifies that the entire name for which the
organizational boundary is being sought is provided to the DNS servers (and
in previous versions, the application/use as well).

2) Sane default.  There needs to be a default behavior that is consistent
and compatible with existing behavior.  With ODUP the lack of DNS data at
an ODUP name (that is, nothing special has been changed for the domain by
way of adding ODUP records) results in behavior that is consistent with the
current behavior [3].  The Levine draft says: "If there is no policy for
the domain the lookup fails; there are no defaults... Applications may
apply defaults of their own, but that is beyond the scope of this
specification."  I'm not sure I fully understand that statement, but it
doesn't provide me confidence that the default is backwards compatible with
current behavior.

[1] See
https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-03
and https://mailarchive.ietf.org/arch/msg/dbound/rRs4EghKGxaxU3AFMCDRKHBkh3w
[2] See https://github.com/verisign/odup for running code and documentation
to recreate this.
[3] Once the ODUP configuration is deployed at TLDs, e.g., using scripts
such as those at https://github.com/verisign/odup