Subject: Re: [dbound] The proposals before us

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Sep 2016 14:43:25 +0000

From: dbound [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, August 30, 2016 11:57 AM
To: [email-masked]
Subject: [dbound] The proposals before us

OK, let's get going.  It's time to make progress or die.
The proposals before us:
* ODUP (https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/)
* John Levine's proposal (https://datatracker.ietf.org/doc/draft-levine-dbound-dns/)
* SOPA (https://datatracker.ietf.org/doc/draft-sullivan-domain-policy-authority/)
Given that we are now constraining ourselves to dealing with the email case only, do we have a clear preference for one of these to adopt and develop?  As I recall, we (especially the authors) all had homework to review these under this new scope constraint and provide critical feedback with a goal of making a selection of some kind for the working group to develop.  Does anyone have such comments to get us moving here?
My team has implemented a proof of concept of ODUP and tested it with some hacking in Firefox and Postfix. It seems to work just fine.

Scott

---

From: "John Levine" <[email-masked]>
Date: 3 Sep 2016 20:57:49 -0000

>* ODUP (
>* John Levine's proposal (
>* SOPA (

My draft expired, so I just uploaded a new -01 which strips out some
of the non-mail stuff but doesn't change the design otherwise.

I'm hardly unbiased, but here's my take on it:

ODUP: first party publication with TXT records, can work but has a lot
of stuff not useful for the mail application.  Number of queries
varies but seems usually to be the number of components in the name.

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.  The draft specifies a new RR with
first party publication but Variations section shows how TXT rather
than RR or third party rather than first party would work.

SOPA: can do all sorts of cool stuff, but the need to put RRs at each
name seems like a show stopper to me.

---

From: Casey Deccio <[email-masked]>
Date: Tue, 6 Sep 2016 11:29:47 -0400

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

> 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

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.

> 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

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2016 01:32:09 -0000

In article <[email-masked]> you write:
>future?  Yup.  I don't think there's a lot of overhead there. ...

I have more opinions, but before expressing them I'd like to see
whether anyone other than the two of us is paying attention.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Sep 2016 00:19:12 -0700

> whether anyone other than the two of us is paying attention.

I am.  I'm working on some comments on our current proposals myself.  Just
don't have them all baked enough to send yet.

Do go on.  :-)

-MSK

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 09 Sep 2016 07:49:17 -0700

> whether anyone other than the two of us is paying attention.

I am paying attention but have conflicting internal opinions on the 
proposals. Overall, though, I hope that this group does in fact do one 
of them and that the result of that is also useful for the web folks in 
some undetermined way.

--Paul

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 10 Sep 2016 08:54:26 -0700

> whether anyone other than the two of us is paying attention.
I am, but have not had time to substantively re-engage with the proposals
before us :-)

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2016 21:13:14 -0000

>future?  Yup.  I don't think there's a lot of overhead there.

Actually, I was thinking of the whole policy-negative stuff.  My proposal
also has slots for other policies, so we seem about the same there.

>tree.

I don't see how that is very useful in practice.  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.

>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).  The horse
has left the barn and I'd rather have the performance.

>doesn't provide me confidence that the default is backwards compatible with

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.

R's,
John

PS: Now I'm definitely going to wait for someone else to say something.

---

From: Casey Deccio <[email-masked]>
Date: Sat, 10 Sep 2016 21:46:06 -0400

Hi John,

> On Sep 10, 2016, at 5:13 PM, John Levine <[email-masked]> wrote:
> 
> 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

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).

> 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

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.

> they do some hack like assume it's a 2LD.  Whatever they do, it seems

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

---

From: "John R Levine" <[email-masked]>
Date: 10 Sep 2016 23:44:39 -0400

> 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):

I have a problem, in that I have read this document multiple times and 
have no clue what the actual series of queries and responses would be, 
given the complexity of the lookup algorithm and the situation where some 
subtrees can be cached via a fetch result. It'd be a big help if you could 
give some examples.

Could you tell us what the queries would be for abc.def.com if the org
domain is def.com, or for ghi.blogspot.com, where the org domain is
ghi.blogspot.com, or jkl.mno.uk and jkl.mno.co.uk, where the org domains
are mno.uk and mno.co.uk?  That would certainly clarify things for me.

>> isn't there, the code does whatever it does. ...

> 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".

Let's say you're looking up the domain bulgaria.xn--90ae.  That's a
name in a real TLD, and the TLD doesn't appear in the PSL.  What does
the code do now?  Looking at some of the PSL libraries, the results
look pretty random.  Some raise exceptions, some fall off the ends of
routines and return null or a random result.

R's,
John

---

From: Casey Deccio <[email-masked]>
Date: Mon, 12 Sep 2016 07:40:15 -0400

> On Sep 10, 2016, at 11:44 PM, John R Levine <[email-masked]> wrote:
> 
> I have a problem, in that I have read this document multiple times and have no clue what the actual series of queries and responses would be, given the complexity of the lookup algorithm and the situation where some subtrees can be cached via a fetch result. It'd be a big help if you could give some examples.

Sure.  Please see Section 6, "Examples":

https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-03#section-6

Table 1 has all the ODUP-related DNS entries.  Figure 1 shows a representation of the affected namespace tree in question.  Figure 2 shows all the queries and responses to ODUP-resolve each and every name in the tree, as the rule in the algorithm corresponding to each response.  Table 3 shows the resolution result.

If you have some local data via fetch, then it's simply as if you didn't have to perform those DNS lookups.  For example, if I have fetched "_odup.uk", then anything under "_odup.uk" doesn't need to be looked up in the DNS.  That includes: a._odup.uk, g.co._odup.uk, and _odup.uk, for example.

> domain is def.com

See example for: b.a.uk

> , or for ghi.blogspot.com, where the org domain is
> ghi.blogspot.com

See example for: c.b.a.uk
(not an exact match, but it's close enough)

> jkl.mno.uk and jkl.mno.co.uk, where the org domains
> are mno.uk and mno.co.uk?

See the examples for b.a.uk and g.co.uk.

>  That would certainly clarify things for me.

Hope that helps.

> routines and return null or a random result.

Fair enough.  Admittedly, the principles behind the current PSL are actually more robust than the current algorithm, data, and implementations.  In theory, given a perfectly complete and accurate PSL, if there's no match, the "public suffix" is the root, which makes the organizational domain the TLD.  In the past this doesn't necessarily make sense, particularly for the cases for which the PSL was originally designed.  However, TLDs aren't what they used to be.  It is clear that many are not intended for general registration, and the TLD itself very well could be the organizational domain.

Casey

---

From: "John R Levine" <[email-masked]>
Date: 12 Sep 2016 09:07:49 -0400

> Sure.  Please see Section 6, "Examples":

Ah, of course.  Oops.  I mostly wanted to clarify that odup does a tree 
walk, so if a hostile sender used addresses like 
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah.example it could 
produce a lot of noise traffic.

> Fair enough.  Admittedly, the principles behind the current PSL are 
> actually more robust than the current algorithm, data, and 
> implementations. ...

In practice, people will write libraries to wrap the calls, and they'll do 
whatever they do if they don't find the data they're looking for.  I agree 
there's no obvious default, since you can't tell by inspection whether a 
TLD is a private vanity TLD, a gTLD that delegates at the second level, or 
something else.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Gervase Markham <[email-masked]>
Date: Mon, 12 Sep 2016 14:30:35 +0100

> routines and return null or a random result.

The PSL algorithm states that if the suffix of a given domain name is
not in the PSL, then the public suffix is the last label - so "xn--90ae"
in your example. And the PSL+1, or "registered/registrable domain" would
be bulgaria.xn--90ae.

Whether this is always correct is a matter for discussion, and whether
libraries do this is a matter for their authors, but that's what the
spec says. See "Algorithm", bullet 2:
https://publicsuffix.org/list/

Gerv

---

From: Casey Deccio <[email-masked]>
Date: Mon, 12 Sep 2016 09:32:24 -0400

> produce a lot of noise traffic.

Yes - it all depends on the DNS setup on the other side.  That is common to
both proposals.

>> actually more robust than the current algorithm, data, and implementations.
>> ...
>>
>

Yes - no obvious default of the nature of a name is the reason why the PSL
and DBOUND exist :)

My point in the earlier email was that the algorithm should be well defined
and with a sane default, so once deployed, if nobody does anything
different, their behavior doesn't change.

Casey

---

From: "John R Levine" <[email-masked]>
Date: 12 Sep 2016 10:17:07 -0400

> Yes - it all depends on the DNS setup on the other side.  That is common to

Nope.  In my proposal the number of lookups depends on the number of 
boundaries, not the number of components.  There'd be a lookup for

a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.blah._bound.example

which would be matched by *._bound.example.  If that returned an answer 
saying that there's a boundary at .example, there'd be a second lookup

a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z._bound.blah.example

that would return NXDOMAIN if there's no subdelegation, and then it's 
done.  The design uses on the closest encloser rule for wildcards to let 
it publish irregular boundaries like *.uk and *.ac.uk.

> different, their behavior doesn't change.

That'd be fine with me, but I wouldn't count on implementers paying more 
attention to this default than to the one for the current PSL.

Regards,

---

From: Casey Deccio <[email-masked]>
Date: Mon, 12 Sep 2016 10:26:26 -0400

On Mon, Sep 12, 2016 at 10:17 AM, John R Levine <[email-masked]> wrote:

> boundaries, not the number of components.

The moment you said "hostile sender", all bets were off.  They make as many
"boundaries" or any other component as they want.

> attention to this default than to the one for the current PSL.

Yes, that's exactly the point of "sane default": don't expect anyone to do
anything different.

Casey

---

From: "John R Levine" <[email-masked]>
Date: 12 Sep 2016 10:36:50 -0400

> "boundaries" or any other component as they want.

Ah, I see your point.  I figured most hostile senders will use other 
people's domains, such as the many wildcarded parked ones.

Regards,

---

From: Casey Deccio <[email-masked]>
Date: Mon, 12 Sep 2016 10:43:41 -0400

> people's domains, such as the many wildcarded parked ones.

Yup.

Also, the walking stops at NXDOMAIN, so unless there's policy way down at
the bottom (which is possible, but not likely, for the typical user), the
walking isn't exhaustive.

Casey