Re: [dbound] The proposals before us

[Casey Deccio <[e-mail]>]

Hi John,

> On Sep 10, 2016, at 5:13 PM, John Levine <[e-mail]> wrote:
> 
> In article <[e-mail]> you write:
> 
>> 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.
> 
> I don't see how that is very useful in practice.

The pertinent information was included in the text that immediately followed the snippet that you included above.  Since it was omitted, I'll include it again here (some emphasis added):

> 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 [1].  Downloading the policy associated with other domains (especially those with heavy usage) brings lookups to zero for names in those domains.

Slightly restated:

The point is that if the entire policy-negative realm (current known as public suffixes) is pulled in using fetch (e.g., using odup2psl.py [1]), then unless an organizational domain below the policy-negative realm has introduced custom policy (by the addition of records in the _odup subdomain), the DNS lookups required are at most one.  If the policy for any arbitrary organizational domain is pulled in using fetch, then no DNS lookups are required.


>  The namespace that
> people are likely to be most interested in is the .COM TLD, but the
> registry doesn't know which subdomains have third-party delegations.
> A domain that doesn't have third-party delegations can publish a fetch
> blob, but in most cases that's only going to say we're one big
> organizational domain.  It's unclear to me if fetch helps domains like
> uk that know that ac.uk and org.uk and co.uk are boundaries but don't
> know what boundaries may exist below that.

I'm not sure I follow your thought patterns.

Current behavior:
The PSL contains a list of all public suffixes.  The organizational domain for a domain name is immediately below the public suffix associated with the name [2].

ODUP:
Each TLD defines bottom-most boundary of the policy-negative realm in the DNS namespace below _odup.TLD.  The organizational domain for a domain name is immediately below the policy negative boundary.

By having all the _odup.TLD zones locally (i.e., obtained using fetch), the boundary of the policy negative realm is known to the application without it making a single DNS query.

For something below the policy-negative boundary (e.g., example.com) if it doesn't already have a local copy of the _odup.example.com zone, then it must make an on-demand DNS query for the records it is looking for.  In the case where there are no such records (i.e., the default case) an NXDOMAIN is returned, and the search stops with just one query.  On the other hand, if it does have a local copy of the _odup.example.com zone, then no DNS queries are required (unless the local copy of the zone indicates that there is another organizational domain boundary).

>> 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
> 
> That is true, but for incoming mail the request will typically be in
> conjunction with a bunch of inquiries about the IP the message is
> coming from (DNSBLs) and the domain in the envelope (SPF).

These DNS queries go to different parties than DBOUND-related DNS queries would go, so it really is additional disclosure.  I suppose whether or not that is acceptable is up to the working group.

> The horse
> has left the barn and I'd rather have the performance.

As already described, when fetch is properly applied, there is no performance disadvantage to ODUP.  Performance and privacy do not  have to be mutually exclusive.

>> 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.
> 
> The current behavior is typically to look in the PSL and if the domain
> isn't there, the code does whatever it does.  I haven't looked at any
> of the libraries to see if they don't look for an org domain or if
> they do some hack like assume it's a 2LD.  Whatever they do, it seems
> compatible to me.

The algorithms on the Public Suffix List page [2] and in section 3.2 of RFC 7489 [3] seem pretty clear.  The algorithm is longest match--there really isn't a notion of "if the domain isn't there".

Best regards,
Casey

[1]  https://github.com/verisign/odup <https://github.com/verisign/odup>
[2] https://publicsuffix.org/list/
[3] https://tools.ietf.org/html/rfc7489