Subject: [dbound] on "control"

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Oct 2015 15:20:01 -0400

Hi,

The glossary at
http://trac.tools.ietf.org/wg/dbound/trac/wiki/Glossary has this:

Control:: (as in "Is domain X under the same control as domain Y")

There are really two different kinds of control here, though, and I
think it's important to make the distinction.  By making this
distinction, I think we reveal something about use cases.  That might
lead us to a solution.

It seems to me that one kind of relationship we want is very close to
what's said above: for any two domain names n1 and n2, in policy terms
is effective control of the domain such that Cn1 == Cn2?  This needs
to be a two-way relationship: n1 should assert that it is in the same
policy realm as n2, and conversely.  If not, then they do not really
share the policy realm.  (I can think of relationships that are
trickier, but they seem to me to be at least problematic.)  This
approach is waht the SOPA record was supposed to do: it asserts the
Start Of Policy Authority, thereby giving us a place to found our
policy-based assertions about how things are grouped together.  As a
happy side effect, we also get a way to disclaim _any_ such bilateral
relationship because you can publish a SOPA record that names the null
set.  This is what "public suffix" domains should do.  Note that this
style of policy is permissive.  It assumes that descendent domains may
have all manner of important relationships between them, and that they
do not implicate the ancestor.

But this does not solve the problem where an ancestor name asserts a
policy by fiat: any delegation I make is required to behave by my
policy, so I can assert that policy and thereby impose it on the
delegated names.  Now, it seems to me that the use cases here come
from the _consumers_ of the data.  Mail administrative domains, for
instance, want to be able to assert their mail policies, and consumers
of the data want to be able to find that assertion point in the tree
because it's the point beyond which they don't have to search.  It's
not necessary for the operator of the domain to use the mechanism to
enforce anything, because the policy is impermissive: it says that
anyone outside the policy is not conforming to the rules for creation
of that descendent domain.  If it were important for the ancestor to
enforce this, it would be simple: delete the domain or delegation.
Instead, this is a way for the ancestor to tell _others_ about the
ancestor policies, so that those others can simply impose the policy
on communications from the descendent.

I think therefore that it would be ok to have two different mechanisms
for these two styles of thing, because the party relying on the
mechanism knows which style of thing it needs.  So it will use the
appropriate mechanism to get the information it needs.

Therefore, it seems to me that we could cover the two different use
cases by refining the SOPA record Jeff and I have already proposed,
and then adding a different mechanism for the second style of problem.
We could call this second case "Parent-Imposed Policy Assertion" (or
PIPA for a nmemonic.  Yes, this tickles me slightly).  The PIPA RR
would in effect assert that it has policy rules that bind descendents.

I am sensitive here to the point that Jiankang Yao made, in that this
is quite a blunt instrument.  In particular, it's not too hard to
imagine cases where one would want a PIPA RR to cover one case and not
another.  One solution for this would be to use a policy document
target along the lines of draft-yao-dbound-dns-solution, but I tend to
feel that's a little complicated.  Moreover, it doesn't follow the
approach already being used by code already deployed.  As I understand
it, that code finds the last point in the public suffix graph that is
an ancestor to the domain name under consideration, moves one label
deeper in the DNS graph, and then uses that as the effective point for
policy.  The same result could be achieved by looking for the last
null-target SOPA record and then searching down the tree for a PIPA
RR, only it would provide greater accuracy.  So I think that the blunt
instrument is sharp enough for what we need.

I'd be interested in people's thoughts about this.  If it seems worth
doing, Jeff and I can update the sopa draft to include this approach.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2015 19:59:08 -0000

>delegated names.

For DMARC, at least, it's not imposed, it's a default.  If
foo.bar.example.com doesn't have its own _dmarc record, it falls back
to the one for example.com.  This is to avoid the SOPA problem of
having to put a record at every point in the subtree.

I can't offhand think of a scenario in which a domain imposes a policy
on an unwilling descendant other than the implicit "not the same as
me" policy of a public suffix cut point.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Oct 2015 16:04:04 -0400

> having to put a record at every point in the subtree.

Yes, I skipped over the part where you looked at the name itself, for
simplicity's sake.  That part is irrelevant to this discussion because
in that case _no_ policy-finding mechanism is going to be invoked.
 
> me" policy of a public suffix cut point.

In every DMARC case where the descendant doesn't have a _dmarc record,
it gets such a policy.  (It's not "unwilling" but "indeterminate
willingness".  The thing is that you don't care what the willingness
is, because in the absence of data some other policy gets used.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Thu, 8 Oct 2015 16:27:50 -0400

Hi Andrew,

> Control:: (as in "Is domain X under the same control as domain Y")
While this was one of the "questions" that were posed for discussion prior
to the DBOUND WG meeting in Prague, it seems to me to be fairly high level
and the least grounded in an actual application problem.  I'm not saying
that it's not worth consideration, but if I had to prioritize the
questions, this one comes after others that stem from current application
needs (e.g., HTTP cookies, DMARC, etc.).

> would in effect assert that it has policy rules that bind descendents.

In general, think you're right - that there are two broad categories of the
problem: identifying policy relationships between a domain name and its
ancestor or descendant; and identifying policy relationships between two
domain names that are not ancestrally related.  This sentiment was
expressed at the DBOUND WG meeting in Prague.  I also had with the
impression from the WG discussion that the two should be considered
separately and that the former was the more pressing than the latter.

My focus as of late has been the former, and I have a draft that will be
submitted soon on that topic--probably Monday.

Casey

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 08 Oct 2015 22:00:52 -0400

> me" policy of a public suffix cut point.

It's not currently in the DNS, but HSTS's includeSubdomains flag seems
to impose a policy on the entire subtree that a descendent should not be
allowed to override.

        --dkg

---

From: "John R Levine" <[email-masked]>
Date: 9 Oct 2015 10:50:18 -0400

> to impose a policy on the entire subtree that a descendent should not be

Good catch.  I missed that.  But when I look at the spec, that bit seems 
sort of half hearted.  They note that if a client fetches www.example.com, 
and there's an includeSubdomains flag at example.com, the client will only 
apply the policy it's previously cached example.com, which as likely as 
not it hasn't.

I don't see this as a strong argument either way for overridable or 
non-overridable assertions about subdomains.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Oct 2015 11:59:33 -0400

> non-overridable assertions about subdomains.

Since we appear to have a small number of cases where ancestor
policies are in some ways inherited down the tree, I think we need
some more clarity here.

It seems to me the case that was important to John and which argued
against the SOPA approach was the DMARC one.  In that case, as I
understand it, the idea is to find the last point of public/private
split in the path from the root to the target domain, and use that.
This only kicks in where the target domain itself has not published a
record.  If the domain _has_ published a record, then the search
doesn't happen.  But if it has not, then you need a way to find a
policy to inherit.

In a case where the ancestor were imposing policy _regardless_ of what
the descendent did, the search effort would I think have to be the
same.  It's just that there would not be the first step of determining
policy at the target name in the first place.

Therefore, I claim, the two cases collapse to one, because once you're
in the mode of looking for some overriding ancestor policy (however
you got into that mode), you're looking for the same thing.

Does that make sense?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2015 17:16:04 -0000

>you got into that mode), you're looking for the same thing.

Pretty much.  The code is nearly the same, only difference is whether
you always look for an ancestor or only if you didn't find something
locally.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Oct 2015 12:02:10 -0400

Hi,

> you got into that mode), you're looking for the same thing.

I didn't get the impression people thought this was nuts.  I admit
that I think it is quite unlikely I will get the update done today
before the deadline, however.  My apologies.

A

-- 
Andrew Sullivan
[email-masked]