Subject: [dbound] Suggestion for Prague: let's try to converge on problem(s)

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Jun 2015 16:31:04 +0100

Hi,

I've been trying to put together detailed comments on
draft-deccio-domain-name-relationships-00, and to propose some changes
to draft-sullivan-dbound-problem-statement-00.  But I'm failing to get
satisfying comments together, so sending this more general remark now
because I think we still have some sort of fundamental gap in our
collective understanding of what we're trying to do.  I'd like to
suggest we use some time in Prague to try to get this sorted out.

In my reading, draft-deccio-domain-name-relationships-00 starts with a
deep, fundamental division between "public" and (for want of a better
term) "private" domain names.  I think it starts there because the
authors genuinely believe that the distinction is a fundamental one.
In my opinion, that stance reifies a distinction that is implicit to
the way the PSL has always worked into a distinction that is part of
the world.

For instance, to me it is extremely artifitcial to claim that the root
zone and (say) the com zone are both "public" zones.  The rules by
which one gets an entry in the root zone are way more convoluted than
the rules by which one gets an entry in the com zone.

By the same token, the important relationship between (for example)
co.uk and uk is not that they're both public, but the way the policy
relationship between those domains works (and how it might evolve over
time).

My view is that this means we need a way to express these kinds of
relationships, but that one thing we _must_ be able to capture (or
perhaps emulate) the public/private distinction that is implicit in
the PSL now.

Part of the reason I keep harping on this is because, if we're merely
going to produce a new way to express the same public/private
distinction we have now, there will be poor incentives to use or
deploy the new protocol.  It imposes some costs, and if you don't get
anything better than the mechanism you already have then the
additional work will never be worth it.

But the problem is, I think, that our use cases suggest that PSL has
been embraced because it's the closest available, rather than being
close enough.  I'd like to spend the time we have in Prague really
hashing the rest of the details of what problems we're really trying
to work on, what ones are must-haves vs. nice to haves, and to
prioritize the nice to have cases in order to understand how we can
make trade-offs.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2015 17:37:48 -0000

>authors genuinely believe that the distinction is a fundamental one.

I share your concern and agree with the implication this jumps to
places we don't necessarily want to be.  It seems to me more useful
to look at the questions are currently answering using the PSL, and
the kinds of answers:

* Should I accept a cookie at this name?  (domain -> yes/no)

* Should I sign an SSL cert at this name? (domain -> yes/no)

* Should I sign a wildcard SSL cert under this name? (domain -> yes/no)

* Where is the DMARC record for this name? (domain -> domain)

* Are these two names under the same control? (domain x domain -> yes/no)

The fact that the questions and answers aren't even all of the same
type should offer a hint that the structure is more complicated.

R's,
John

---

From: Gervase Markham <[email-masked]>
Date: Wed, 17 Jun 2015 19:20:29 +0100

> * Should I sign an SSL cert at this name? (domain -> yes/no)

Again, the PSL does not give a yes/no answer to this question. It gives
a "yes if everything else checks out/probably not but check carefully"
answer. The real answer depends on factors external to both the PSL and
the DNS.

Gerv

---

From: Casey Deccio <[email-masked]>
Date: Wed, 17 Jun 2015 14:48:05 -0400

Hi Andrew,

Well said and proposed.

Some additional comments inline.

> the way the PSL has always worked into a distinction that is part of

Part of my reasoning for writing this draft is that I believe that the
fundamental division between (currently called) public and private names,
brought to light by the PSL, is a great asset in solving this problem.
Understanding that division--and properly defining it--can help with
identifying solution(s).  That is not to say that the PSL is 100% accurate
in implementing this distinction, nor is the PSL sufficient for determining
policies.  I am well aware of that.  However, I argue that a line can be
drawn through the breadth of the DNS namespace tree, above which names are
not to be associated with names below, as far as policy relationships are
concerned--even if those names above and below the line are administered by
the same entity.  If such is not true, then the line needs to be moved up
until it is.

Solutions have been proposed to more generally associate names for policy.
Something of that nature is probably necessary.  However, the proposals
I've read thus far come with considerable complexity and high risk of
"getting it wrong".  It's not to say that they wouldn't work, and perhaps
they can be improved within the working group to lower that risk.  But the
point of the boundary I'm referring to (and implemented, to some extent, by
the PSL) is to cover many (most?) cases by simply identifying this boundary
where the names in question are in relation to that boundary.  If something
cannot be determined with this boundary, other, more specific mechanisms,
can be used to supplement.  If someone doesn't want to use this boundary at
all, then they simply move the line up, effectively making it
"opt-in/opt-out".

In other words, while the PSL concept is incomplete, there is a lot of good
in it, and the ideas can exist even alongside other DBOUND solutions, to
provide "sufficient" means for domain name policy, where other complexity
is neither additionally useful nor desired.

> relationship between those domains works (and how it might evolve over

This all depends on what you want to know about them.  But I would argue
that for many (most?) cases the fact that they're both public is
"sufficient".

> additional work will never be worth it.

I'll reiterate here, that while draft-deccio-domain-name-relationships-00
discusses public/private boundaries, neither the draft nor I am encouraging
a solution that merely produces a new way to express the same
public/private distinction--only that the distinction can be used to lift
the complexity burden of other, more heavy-handed solutions, so dismissing
the current paradigm entirely in order to get it "right" with one silver
bullet solution is probably not the right way to go.

Cheers,
Casey

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Jun 2015 11:19:47 +0200

Hi,

> brought to light by the PSL, is a great asset in solving this problem.

Yes, I know, and that's exactly what we disagree about.  I think that
this simple division causes as much harm as benefit.

> the same entity.  If such is not true, then the line needs to be moved up

And I am arguing that "a line" is a fundamental mistake.  Moreover, in
my view the idea that these are always or even primarily parent-child
relationships is a serious error (but I recognise that that is a more
controversial point of view).

> where the names in question are in relation to that boundary.

I think we disagree about what the facts are here, because I don't
think the evidence before us gives us a reason that this single
boundary works today.  I argue that this is not because the details in
the PSL happen to be wrong (sometimes they are, but it's at least 80%
good), but because the PSL or any other single-factor distinction is
making a category mistake.  I think that John's questions upthread are
a much better foundation from which to proceed.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 19 Jun 2015 06:55:16 -0700

I completely concur with John's more organic-friendly questions, and also
agree that a simple line as a boundary is not the right approach.   CONTEXT
is absolutely important.

If we iterated through John's cases, it clearly demonstrates how things can
be different per namespace per context.

Context of use case ABSOLUTELY matters and it changes where any theoretical
boundary exists, and context might also alter where boundaries are defined
within namespaces (or if they) should.

I have tried to make a few captures of what we might benefit from including
in thoughts and discussion around the problems to solve.

I don't wish to prescribe any solution in doing so, it is just a brain dump
mostly.  As I re-read them, I notice that we might benefit from thinking
about organizing them per context, vs per namespace, but again, I fear I
may be being prescriptive.

Parent/child
It seems like parent-child relationship is important to "domain
boundaries", but records reflecting these should come with associated
context also documented, to define child(ren) suffixes

Contexts
There should also be flexibility to allow for multiple contexts and
variance to where these boundaries are.

Administrative errata
Having a place to indicate some form of normalized information, such as
Whois server address for domains in it
Abuse poc
Registry URL
Registry policy URL
Code points (If IDN)
Etc.

Apex
It does seem important, in the context of apex of root authority, (and also
registry) to demonstrate top down chains of parent-child relationships like
might exist between "." and ".uk" or ".uk" and ".ac.uk", such that ".ac.uk"
and be known to be part of an authoritative administrative chain,
unbroken, within ".".

I always seem to pick on Centralnic names, but this would be true of any
subdomaining entity like Amazon AWS or Dyn, but having some way for .com.de
or co.com to self-represent apex within their record somehow to establish
that they are not within the top down apex from the root, but are
expressing other contexts and records to indicate what is appropriate
within these namespaces for cookie behavior, certificate issue, etc.

In doing some form of element to show administrative apex, there needs to
be care to do so in a manner that would not prejudice self-apex types that
may not have a chain of authority from the parent  (like Github, Dyn,
Centralnic, Amazon. Etc) that are not administratively connected all the
way up to the root delegation.

A commentary about caution and why I am inclusive about representation for
subdomain entities, is that I could see a registry potentially salivating
over charging a registrant extra to obtain a special connection/license to
subdomain.

We should be careful about ensuring no disruption, financial, operational,
or otherwise, to the operators of subdomain solutions, whatever we label
them as.

Equivalence
if there were some way to add aliases for equivilence - such that PIR
.ONG/.NGO or other similar situations where registry makes paired names
available - that we could have some alias record that could reflect this,
per context.

-jothan

On Friday, June 19, 2015, Andrew Sullivan <[email-masked]> wrote:

> [email-masked] <javascript:;>
>
> _______________________________________________
> dbound mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dbound
>

-- 

Jothan Frakes
Tel: +1.206-355-0230

---

From: Casey Deccio <[email-masked]>
Date: Fri, 19 Jun 2015 11:40:40 -0400

Hi Andrew,

On Fri, Jun 19, 2015 at 5:19 AM, Andrew Sullivan <[email-masked]>
wrote:

> And I am arguing that "a line" is a fundamental mistake.

I'm not sure why it is a mistake or why that mistake is fundamental.  It
all depends on how that line is to be used, which helps determine where the
line is, correct?

> Moreover, in

I'm not sure that I've ever conveyed that idea.  If I have, it was
unintentional.  The purpose of the current PSL or some future mechanism
that operates on similar principles is not to identify relationships but to
define a boundary across which they can be repudiated.  In many use cases
that is sufficient.  Where it is not, other mechanisms can be used to
identify them (i.e., other solutions within DBOUND).

> boundary works today.

"Works" is unfortunately a very ambiguous term.  Does it work to serve the
primary purposes for which it was originally developed (e.g., HTTP cookie
domain limits and (later) rudimentary identifying of "non-public" parts of
names for display purposes in your browser's location bar)?  Does it
fulfill those primary purposes for one or both of the two "categories" of
suffixes in the file?  Does it work for other applications (e.g., DMARC)
for which it wasn't originally designed?  For each previous question, what
is the proportion of cases for which it has been successful and when it
hasn't?  The answers to each of these questions will likely vary (probably
with decreasing success rate in the order in which they were asked).

Previously, and again here I reiterate the following: I do not believe the
current PSL or some future PSL-like mechanism can solve *by itself* what
DBOUND has proposed to solve.  Period.

What I have continually suggested is that part of identifying relationships
is repudiating relationships.  And if there's a simple way to do *first*
this, how often will this check suffice?  When it does suffice, none of the
other, more complicated, mechanisms need to be utilized.  But it doesn't
suffice, then the client has other avenues.

I argue that this is not because the details in
> good),

What do you mean by "at least 80% good"?  Are you saying that up to 20% of
the list is inaccurate?  Or that up to 20% of the use cases of the list are
inaccurate?  Or are you talking about actual uses?  Where did you get these
numbers?

but because the PSL or any other single-factor distinction is
> making a category mistake.

Yup.  Again, I am not, nor have I, advocated a single-factor distinction.

I do not believe the current PSL or some future PSL-like mechanism can
solve *by itself* what DBOUND has proposed to solve.  Period.

> I think that John's questions upthread are
John's questions are great.  And to me they show how a hybrid mechanism can
work.  For demonstrative purposes only (purely examples):

* Should I accept a cookie at this name?  (domain -> yes/no)
Flow:
1. is there a public boundary between name and domain? yes: goto 5; no:
goto 2;
2. is there (using some other DBOUND solution) a policy governing the
domain? yes: goto 3; no: goto 4;
3. does policy allow name to set cookie for domain? yes: goto 6; no: goto 5;
4. does RFC 6265 allow name to cookie for domain? yes: goto 5; no: goto 6;
5. "no"
6. "yes"

* Should I sign an SSL cert at this name? (domain -> yes/no)
Flow:
1. is name above a public boundary? yes: goto 4; no: goto 2;
2. is there (using some other DBOUND solution) an SSL cert policy governing
the name? yes: goto 3; no: goto 5;
3. does policy allow the name to qualify for an SSL cert? yes: goto 5; no:
goto 4;
4. "no"
5. "yes"

* Should I sign a wildcard SSL cert under this name? (domain -> yes/no)
1. is name (minus wildcard) above a public boundary? yes: goto 4; no: goto
2;
2. is there (using some other DBOUND solution) an SSL cert policy governing
the name? yes: goto 3; no: goto 5;
3. does policy allow the name to have a wildcard SSL cert? yes: goto 5; no:
goto 4;
4. "no"
5. "yes"

* Where is the DMARC record for this name? (domain -> domain)
Do you mean what is the "organizational domain" for this domain (i.e., RFC
7489, section 6.1)?
1. is there (using some other DBOUND solution) a policy to identify the
organizational domain of name? yes: goto 2; no: goto 3;
2. the organizational domain of name, as produced by the solution found in
1 (perhaps this would have an additional check to make sure it's not above
a public boundary).
3. the name formed by identifying the lowest public boundary, plus one
label (i.e., as in RFC 7489, section 6.1)

* Are these two names under the same control? (domain x domain -> yes/no)
Under the same *control* or the same *policy*?  The process here would vary
based on the answer and might not involve DBOUND at all.

So you might still be asking: if the "other" (i.e., non-PSL-like) solution
could essentially stand alone, why even include that solution?  I can think
of a number of reasons, one of which, I've already mentioned, is for the
"default" case (i.e., where there is no explicit policy--either by choice
or by disregard/ignorance).  I've said that this "default" case could apply
to the vast majority of names.  I say this because if the name (or
organizational domain) happens to coincide with the name directly below the
public boundary, then in most cases, there's no more to be done!  I suspect
that this is a large number, but I don't have stats.  And again, I'm not
saying that there aren't cases where this doesn't work!

This also provides inherent backwards compatibility.  Additionally, if
implemented in a fashion like the current PSL, much of this can simply be
done offline.  Finally (and in conjunction with the self-contained, offline
capability) the client can determine with what granularity it wants to
identify (or repudiate) an association.  For example, think identifying
organizational domains (for lack of a better word) for log messages.  I
can't imagine a system administrator wanting to perform online lookups to
identify organizations for names associated with log messages.

Cheers,
Casey

---

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

>I'm not sure why it is a mistake or why that mistake is fundamental.

Because it's not necessarily a line.  For DMARC, it would be really
nice if we could say that the policy record for names at and below
foomail.ca and foocourriel.fr and foopost.de and foomail.co.uk is at
foomail.com. For cookies we'd like to say that google.com and
1e100.com are under the same control. In general, we want to say that
<x>.ong and <x>.ngo are under the same control for any <x>.

Maybe those are too hard, but I don't want to rule them out until we
understand what the real options are.

R's,
John

---

From: Casey Deccio <[email-masked]>
Date: Fri, 19 Jun 2015 15:45:20 -0400

> understand what the real options are.

For the case you've given, assume "the line" is above all the names.  Can
it tell you anything about their relationships?  No - only that it cannot
repudiate any relationships.  This is why I've repeatedly said that
identifying "the line" is not a stand-alone solution, and why more specific
solutions must be adopted to meet the larger DBOUND question.  That doesn't
mean that "the line" cannot help simplify the description/configuration and
be sufficient for the more common cases (and a sane default when no
configuration is given) .

Casey