Subject: [apps-discuss] "finding registered domains"

From: Andrew Sullivan <[email-masked]>
Date: Sat, 9 Mar 2013 23:22:50 -0500

Dear colleagues,

In the APPSAWG meeting on Monday, the chairs have asked me to take
five minutes on the subject: topic.  I thought I'd better send a note
in preparation.

ICANN is in the process of awarding a little under 2000 new TLDs.
Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested
a new DNS RRTYPE that would identify a name as a public suffix.
Unfortunately, he fell ill and didn't have a chance to submit a draft
on this.

I'm opposed to that particular idea, however, because I think I have
proposed a more generic mechanism that would still work just as well
for that use case, and also allow future refinements.  I've outlined
that mechanism in
http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02.

I won't have any slides on Monday; I really just want to learn the
following:

    1.  Do people think this is work that needs to be done?

    2.  Do either of the above proposals seem like a good starting
    point?

    3.  If so, who is willing to do work on this (by reviewing and so
    on).  

(3) is especially important to me, because I received rather too
little feedback on the draft I offered to think that anyone else is
interested in pursuing it.  If people are interested in that draft,
I'm certainly prepared to continue working on it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 10 Mar 2013 09:09:21 +0100

> http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02.

I must be tired or have not had enough coffee yet this sunday morning, but I can not really follow the text in your I-D. Not a complaint on the I-D, or the idea...

I feel two things are included in the proposal:

1. Whether for example cookies should be set on the domain name
2. Whether two (or more) domain names are within the same policy domain

I think the first is the most important issue. Similar ideas have been discussed around the "delegation only" discussions, but this is of course slightly different.

Early in the text I see:

> The idea is to foil the attempts of attackers in (for
> example) attackersite.co.tld from setting cookies for everyone in
> co.tld.

I feel that can be solved by having a resource record like this:

co.tld. IN SOPA 255

...where the value 255 implies no cookies, certificates or whatever is to be set for the owner co.tld. Other values than 255 can be allocated for other meanings.

This will be managed by either the owner of tld if there is no zone cut, or co.tld if there is a zone cut.

Maybe I am naive, but that I feel could be useful.

For the 2nd idea, to say whether two records belong to the same policy domain, hmm..., I must get more examples I think of what that is to be used for by third parties.

Maybe only the first problem should be solved (first)?

And of course, if I am completely off, just disregard this message.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Mar 2013 10:21:56 -0700

>    1.  Do people think this is work that needs to be done?

Yes. The idea keeps coming up in various venues, and people default to the Public Suffix List because there is nothing else, even thought that list is often out-of-date.

>    2.  Do either of the above proposals seem like a good starting

draft-sullivan-domain-origin-assert seems like a good starting point.

>    3.  If so, who is willing to do work on this (by reviewing and so

I am willing to review and contribute text and examples.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Mar 2013 14:29:28 -0400

> 2. Whether two (or more) domain names are within the same policy domain

I claim that (1) is actually just an instance of (2), and it just so
happens to be the worst irritant of these cases so it's the one people
talk about.

> This will be managed by either the owner of tld if there is no zone cut, or co.tld if there is a zone cut.

A significant point of this proposal is to get this away from trying
to use the zone cut as in any way meaningful in this context.  It's
the illusion that a zone cut tells you anything here that we need to
combat.  That was a category mistake that people made early on.
Moreover, when I initially thought about this, I thought that maybe we
could link the SOPA record to zone cuts; but I quickly realized that
the zone cut is really an orthoganal issue, and we shouldn't nail this
problem to that one.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 10 Mar 2013 20:03:16 +0100

> combat.  That was a category mistake that people made early on.

Yes, I remember that, agree with this try to get out of that trap, but I fell into it :-(

> the zone cut is really an orthoganal issue, and we shouldn't nail this

Sorry for using that term. My fault.

Let me express it differently, "should a cookie (etc) be possible to set for this domain name?"..

   paf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Mar 2013 15:12:30 -0400

I think that there are two separate sets of security requirements here
and there is therefore a need to be able to state either

* This domain is a public delegation point
* This domain is NOT a public delegation point.

Andrew's proposal seems to be limited to the security issues of
cookies. I think there is a much better way to solve the security
problems of cookies, one that is guaranteed to be 100% reliable,
albeit not one that is likely to be acceptable...

The reason I want both types of assertion is that we use the public
suffix list in a different way when we are issuing a certificate and
the security concerns are rather different as a result. In particular
CAs are only ever going to consider information retrieved from the DNS
as 'evidence'. It is never going to be considered to be 'proof' and
never relied on to the exclusion of any other information.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Mar 2013 07:42:04 -0400

Looks like my plane is not getting in till 10:15, probably won't make
apps area wg.

My main concern is that anyone with useful information be able to
share it through the DNS rather than perpetuate a host of external
registries and folklore.

The new TLD operators are positioned to provide information and that
would be useful.

Switching the cookie protocol so that it is less insane seems like a
good thing to do but takes longer.

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 08:22:33 -0400

On Sun, Mar 10, 2013 at 03:12:30PM -0400, Phillip Hallam-Baker wrote:
> cookies.

I don't see why.  In fact, quite the opposite.  

I think the "public delegation point/not public point" dichotomy is
too narrow.  In general, we can say that for administrative purposes,
there are possible close administrative relationships between names.
One such relationship is "none".  If such a name also has any
names beneath it, then for the purposes of cookies (or CAs, or
anything else) it is a public "delegation" point.  (Note the scare
quotes.  Delegation is strictly speaking a matter of adding apex
records at that point in the DNS graph.  But that's not relevant here:
think of "web hotel" kind of cases, which needn't delegate and yet are
clearly cases where the different names are not in the same
administrative realm.) 

If you don't treat the "is this a public delegation point?" as an
empirical matter (are there names beneath me?), then you are subject
to assertions by people that they do not do public delegation, when in
fact they do.  I'm sure there's some genius in some new TLD applicant
company who would like to turn that into a "feature".

> never relied on to the exclusion of any other information.

Of course.  It's the DNS, not the Lord's Promise Protocol :)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "J. Trent Adams" <[email-masked]>
Date: Mon, 11 Mar 2013 12:07:27 -0600

Coming up with a workable solution for identifying administrative
boundaries within domains is clearly important for many known use cases,
plus a sufficiently general solution would service many more uses that
are currently unknown.  We undoubtedly need to ween ourselves from the
public suffix list, especially as the longer the issue is left
unaddressed the more hacks or non-scalable work-arounds that will
proliferate.

As a case in point, the emerging DMARC work would benefit from this type
of solution.

Having read
http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 pretty
closely, and discussed it with my colleagues, I believe that this is a
perfectly reasonable starting point.

I don't believe it's the perfect solution in its current state (and I
personally prefer the name-only variant), but believe we can easily use
it as a solid aggregation point around which to build the right solution.

Yes, I can commit to spending time on this work.

Thanks,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Mar 2013 14:14:08 -0400

+1 to all of Paul's answers.

-MSK, participatizing

On Sun, Mar 10, 2013 at 1:21 PM, Paul Hoffman <[email-masked]> wrote:

> Yes. The idea keeps coming up in various venues, and people default to the
> Public Suffix List because there is nothing else, even thought that list is
> often out-of-date.
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Mar 2013 16:23:25 -0400

For the sake of taking some hallway track conversation and writing it down
somewhere:

The origin for this work from my perspective is the need for being able to
make policy statements about a registered domain and all of its
subdomains.  For example, given a.b.c.d.example.com, I'd like to be able to
discover somehow that a domain-level policy record could be found at
example.com, where example.com is the domain name that has been assigned by
a registry.  This would allow for example.co.uk to be similarly discovered,
i.e., the solution accommodates the idea that delegations don't happen at
the first label.

Today I learned that there's also a need for a solution to this or a
similar problem related to the use of cookies.

I'd like to understand how these are related, or instead how they are
actually totally different problem spaces.  I think this is important to
figuring out a path forward.

This has nothing to do with Andrew's proposal directly.  I'm just trying to
establish what the audience(s) might be, rather than focusing on my
specific use case.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 17:08:57 -0400

> figuring out a path forward.

In my opinion, these are in fact the very same problem, just with
different expressions.

At bottom, the issue is always that there is an attempt to read from
the hierarchical delegation space of the DNS some sort of
administrative commonality that just doesn't exist.  

In general, domain names just represent the labels of every node down
the DNS tree from the root zone.  So, the name
label1.label2.label3.example.com. names several levels of the DNS
tree.  And labelA.labelB.labelC.example.com. also names several levels
of the DNS tree.

What we _cannot_ tell from any of that is who is in control of which
parts.  This is true regardless of whether there are any delegations
(SOA records) in the tree anywhere along that FQDN.  You can tell that
example.com in both FQDNs are under the same control (because they're
the same node), but you can't tell whether example.com is controlled
by the same people who control .com (compare this with the co.uk/.uk
case).  Similarly, you cannot tell whether
labelA.labelB.labelC.example.com. is controlled by the people who
control example.com (compare this to web hotels, for instance, which
have of course mostly fallen out of fashion for this reason).  There
are some historically good pretty good rules of thumb, but that's all
they are.

The "cookies problem" is just a special case: the cookies spec had
peculiar rules about TLDs, and now has some special handling of
sibling and children relationships, but it's still both too broad and
too narrow.

Does this help?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Mar 2013 08:37:12 -0400

It's very helpful, thanks.

So for the sake of looking through all of our options, could you (or
anyone) comment on why we might not want to do a downward tree walk looking
for a first administrative boundary record?  It seems like those walks are
limited to only a couple of queries at most and could be cached for a very
long time.

It's also been suggested that maybe the solution for this should come from
WEIRDS.  The reason that might be is that we're trying to impose onto the
DNS some structure that isn't there (I hope I'm paraphrasing my DNS
colleagues properly there), so maybe the answer to this question should
also come from outside the DNS.  Is that something that deserves serious
consideration, or is it off the mark?

-MSK

---

From: "Hill, Brad" <[email-masked]>
Date: Tue, 12 Mar 2013 14:23:18 +0000

Andrew,

  Thank you for this important draft.  A few comments:

 1) I support the idea that we need something more maintainable than the public suffix list for several purposes, and I think this is a good starting place.

 2) I prefer the names-only version.  I think the protocol / port issue is an unnecessary complication.

 3) I think if this is going to live in the DNS, it should respect the structure of, and say things about, the DNS, rather than describing a distinct and arbitrary overlay topology of administrative trust relationships.   In particular, I think the ability to make statements like "example.com and example.net should be able to share cookies" is a very bad idea.    It is a feature that web developers have wanted forever, and one I'm glad they have never gotten.   Rather than be an edge-case, I think you would find a few things here:

   a) "cousin domains" like this are actually quite common
   b) certain large entities would be able to exert considerable market power to demand that organizations create these kinds of linkages in the DNS to enable cookie sharing for extremely common scenarios like tracking and analytics, advertising or single-sign on

  These two things would lead to:

  i) highly dynamic data that downstream consumers of a cached data set (web  browsers) are not prepared to handle
  ii) a very large amount of data that downstream consumers of a cached data set are not prepared to handle
  iii) this would make the web more brittle and insecure.  The need to do explicit and loosely-coupled linkages across these boundaries today, rather than simply relying on promiscuous cookie sharing, is a very good thing for the web, IMHO.

The current restrictions on moving up/down the hierarchy only have been workable thus far - there is little pressing need to change this, and I think we do so at great peril. (and with a high likelihood that browsers would simply refuse to honor any such notations)

4) I am also concerned with mixing the state of siblings as to whether they share an administrative relationship with the parent or not.  Whether the depth in the DNS hierarchy is a "real" thing or not, it has been treated as such and been a part of the web security model for almost 20 years.  The "walk towards the root until you find a boundary, and all siblings are equal" procedures apply not just for setting cookies, but to core JavaScript and therefore the Same Origin Policy through a feature known as "domain lowering".  Domain lowering is the property that a web application is able to "lower" its effective domain. (e.g. from x.y.z.example.com to y.z.example.com, z.example.com, or example.com)  While this may sound kooky, it's actually the basis of some widely used patterns. (http://blogs.msdn.com/b/dthorpe/archive/2007/09/27/cross-domain-communication-using-domain-lowering.aspx)  I think that you will find a very uphill battle to try to change this model - many sites depend on it.  And again, it has worked pretty well, despite its warts or whatever lack of respect for the true semantics of the DNS it showed in its original design.

tl;dr: remove most of the complexity and use this mechanism only to identify the depth(s) at which a delegation occurs, with no scheme/port, no cross-linkages, and all siblings equal

cheers,
Brad Hill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Andrew Sullivan
> Sent: Saturday, March 09, 2013 11:23 PM
> To: [email-masked]
> Subject: [apps-discuss] "finding registered domains"
> 
> Dear colleagues,
> 
> In the APPSAWG meeting on Monday, the chairs have asked me to take five
> minutes on the subject: topic.  I thought I'd better send a note in preparation.
> 
> Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested a new DNS
> RRTYPE that would identify a name as a public suffix.
> Unfortunately, he fell ill and didn't have a chance to submit a draft on this.
> 
> I'm opposed to that particular idea, however, because I think I have proposed a
> more generic mechanism that would still work just as well for that use case,
> and also allow future refinements.  I've outlined that mechanism in
> (3) is especially important to me, because I received rather too little feedback
> on the draft I offered to think that anyone else is interested in pursuing it.  If
> people are interested in that draft, I'm certainly prepared to continue working
> on it.
> 
> Best regards,
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 14:40:51 -0400

> consideration, or is it off the mark?

I actually originally thought that would be way better.  The problem I
ran into is that anyone who is running a domain name already has, by
definition, a DNS server.  An overwhelming number of them don't have a
WEIRDS service, and probably don't want to run one.  That's what makes
me reluctant to go in that direction.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Mar 2013 15:51:23 -0400

I was not there for John's comments but from what I gather of them
second hand I completely disagree.

It does not matter what the DNS was designed to do twenty years ago.
That is a debate for historians. What the DNS was intended to be has
never been the same as what people used it for or found value in. The
fact that people use the DNS in ways that were not anticipated by the
designers is not a bug, not something to be corrected.

How the users of the Internet use the DNS is all that matters now.
Telling people that they don't want to do what they are trying to do
is silly and insulting.

There is an implicit administrative hierarchy in DNS. There is a real
world distinction between DNS delegations that are private and those
that are public. The applications layer of the Internet has built on
those assumptions for the past twenty years

What would be a mistake is to propose the use of any infrastructure
that is not DNS to publish authoritative statements about DNS names.
That would be a violation of the Internet architecture. Please, no
more talk about WEIRDS or whatever other protocol someone might see a
chance to find a use case for.

I do not need the full capabilities expressed in Andrew's draft. In
fact I only need two statements, both of which could be specified in a
new DNS RR or if we don't want to add new RRs we could even use the
existing CAA record and express them as properties.

The properties I need to be able to express in a domain are:

PUBLIC - This domain is a public delegation point
PRIVATE - This domain is not a public delegation point
EXCLUDED - This domain is excluded from the enclosing private space.

So taking the example of ai.mit.edu we would have:

edu          PUBLIC
mit.edu    PRIVATE
ai.mit.edu   EXCLUDED

edu is a public delegation point. Anyone with a school can get a domain.

mit.edu has domains registered below it but it is not a public
delegation point. You have to be affiliated to MIT to get a domain.
There is an accountability infrastructure in place.

ai.mit.edu was a sub domain but one that always had a separate network
administration which might mean that it was appropriate for it to be
declared as being separate from the rest of the *.mit.edu space so
that cross site issues were avoided in both directions.

Note that all the above information are simple statements of fact that
the administrators of the domain might make. Interpretation of those
statements is a completely different matter.

The mere fact that a domain has an assertion in the DNS at issue time
does not mean that I am automatically going to rely on it when issuing
certificates. We crawl the web constantly. If the information being
published now is inconsistent with the information published
consistently for the past 4 years, that may require a closer look.

I would expect that the information proposed would be used to inform
the compilation of 'public prefix lists' but those are going to remain
a curated resource. Publication in DNS is not ideal but a lot better
than an open access wiki (see error 81).

We have in the next 12 months an opportunity to tell ICANN that we
would like the winners of the new TLDs to publish records declaring
the public delegation points. This has essentially zero cost to ICANN
but allows the maintenance of public prefix lists to scale in the wake
of the TLD expansion.

All that is necessary to make that happen is to provide a clear and
simple specification for those TLD operators to deploy. If we miss
that window it will be a lot harder.

When I started this note I was thinking that re-use of CAA was a bit
of a hack. But considering the fact that the division between public
and private was one of the main design issues we ended up having
problems with, it actually looks like a pretty clean fit to me right
now.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Mar 2013 15:52:20 -0400

I mean a WEIRDS client, not a server.  WEIRDS clients include anything that
can do an HTTP query.

If for example I decide I need to evaluate foo.bar.example.com, I would
issue a WEIRDS query for that string, and presumably get back
example.comas that's the registered domain.  (This is a particular
point for the
WEIRDS community to confirm.)

This introduces a rather dire need for caching, but that's another matter.

---

From: "John Levine" <[email-masked]>
Date: 12 Mar 2013 20:07:06 -0000

>   b) certain large entities would be able to exert considerable market power to
>demand that organizations create these kinds of linkages in the DNS to enable
>cookie sharing for extremely common scenarios like tracking and analytics,
>advertising or single-sign on

Now that you mention it, ewwww.  This would basically allow ad
networks to assert that third party cookies are first party cookies.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 16:19:15 -0400

Brad,

Thanks for your comments.  Some more questions inline below.

>  2) I prefer the names-only version.  I think the protocol / port issue is an unnecessary complication.

Everyone seems to think that, and I'm relieved, so if there's another
draft I'll remove that.

>  3) I think if this is going to live in the DNS, it should respect
>  the structure of, and say things about, the DNS, rather than
>  describing a distinct and arbitrary overlay topology of
>  administrative trust relationships.   

Just to be careful here, no matter _what_ we do, we are describing an
arbitrary overlay topology of administrative trust relationships.
That is necessarily true, because the relationships that currently
exist in the DNS are DNS-topological only.  People are _used_ to the
idea that names are related to one another in particular ways, and as
a cultural fact that is mostly true; but in the not very distant past,
it wasn't, and there's reason to suppose it might not obtain in the
near future.

>   ii) a very large amount of data that downstream consumers of a cached data set are not prepared to handle

This issue had, I have to confess, never even occurred to me.  You're
quite right, however, that the design of the mechanism tends to
encourage a default position of "don't trust, no need to look up," but
the design of the cross-tree declaration will tend to encourage a
large number of queries that are not broadly applicable and that will
therefore not be very good cache candidates.  For practical purposes,
therefore, I'd be tempted to say that, in any SOPA record, the owner
name must be related to the name in the RDATA as either an ancestor or
a descendent (with the root label still being the special case of "not
here"; of course, every name is related to the root label).

> 4) I am also concerned with mixing the state of siblings as to
> whether they share an administrative relationship with the parent or
> not.  Whether the depth in the DNS hierarchy is a "real" thing or
> not, it has been treated as such and been a part of the web security
> model for almost 20 years.  The "walk towards the root until you
> find a boundary, and all siblings are equal" procedures apply not
> just for setting cookies, but to core JavaScript and therefore the
> Same Origin Policy through a feature known as "domain lowering".

I take very seriously the argument that there is an existing and
widely-deployed model.  I note, however, that the widely-deployed
model is about to be thrown out anyway, regardless of how we feel
about it.  For a significant number of the new TLDs are so-called
".brand" TLDs, and I'm pretty sure that the operators of .megacorp are
going to want to be able to set shared cookies in www.megacorp and
product1.megacorp and so on.  

It seems to me, however, that we might need a way to make this sort of
behaviour the default.  The wildcard trick was intended to make that
easy, but I'm not perfectly sure it will.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 16:24:42 -0400

> WEIRDS community to confirm.)

Why would the correct answer not be from foo.bar.example.com or
bar.example.com (or, actually, both)?

A large amount of the assumed background is the deployed convention of
label.example.com.  The "registered domain" here is example.com.  And
while that is the most common case, it doesnt cover everything.
Indeed, if that convention _were_ reliable, we wouldn't need the
public suffix list at all.  

Moreover, if my parent can assert things about me, then unless I run a
WEIRDS server I wouldn't have a way of disagreeing with that parent.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Mar 2013 16:30:46 -0400

> 1.  Do people think this is work that needs to be done?

Yes. The public suffix list must die.

> 2.  Do either of the above proposals seem like a good starting 

I'll need time to read your draft in more detail before forming an
opinion. What is the other proposal?

> 3.  If so, who is willing to do work on this (by reviewing and so 

I am willing to review and provide feedback.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Mar 2013 16:37:10 -0400

> bar.example.com (or, actually, both)?

I am probably making some assumptions here, about which I should be careful
given the weird hat that's around here somewhere.  It's based on a property
of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4, then
I will get back the registration for the tightest containing subnet
registration, and possibly all of them upwards.  If a WEIRDS server did the
same with names (or could if asked), then example.com would be the returned
result for foo.bar.example.com.

> WEIRDS server I wouldn't have a way of disagreeing with that parent.
The particular use case I'm working on here applies an algorithm like:

a) ask about the domain name I have
b) if I don't get an answer, figure out the registered domain (currently
using public suffix) and ask there

So you (at (a) in that list) can override what the parent says if you need
to.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 16:46:53 -0400

> opinion. What is the other proposal?

The other proposal is an undrafted one, but it's basically what Phill
posted to the list earlier today: a way of indicating that you do
delegate or do not delegate to other organizations, and another way of
asserting that no matter what others say, they so are not inside your
policy authority boundary.

I suppose it requires writing up.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 16:50:07 -0400

> result for foo.bar.example.com.

But why should you believe what example.com says about
foo.bar.example.com?  If we could believe that, we wouldn't need a new
mechanism.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "J. Trent Adams" <[email-masked]>
Date: Tue, 12 Mar 2013 15:06:40 -0600

Andrew -

> foo.bar.example.com?  If we could believe that, we wouldn't need a new

There are times in practice when it's useful to make certain assumptions
like "if there is no response to a given query at a FQDN, hop all the
way to the registered domain to see what it says."  That's not to say
that this model fits all use cases, just that sometimes it's helpful
(and your proposal seems to support it by pointing me in the right
direction).

So, for example, I'd publish a SOPA record at "way.down.the.tree.org"
pointing to "tree.org".  Then if what I'm looking for doesn't exist at
"way.down.the.tree.org", I would know that the answer is at "tree.org".

This may actually be a bastardization of what you're ultimately trying
to accomplish, but does seem to serve my goals with the added benefit of
weening myself off of the public suffix list.

- Trent

-- 
J. Trent Adams

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Mar 2013 18:58:28 -0400

In my use case, it's defined that an example.com policy is used (if it
exists) in the absence of a foo.bar.example.com policy.  The problem is I
don't know how far up the tree to make that second query.

So in my case I explicitly will believe the parent/grandparent/whatever
statement, but I don't know how far up to go, and I don't want to ask
everyone; I only want to ask at most two questions.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 23:17:56 -0400

On Tue, Mar 12, 2013 at 03:06:40PM -0600, J. Trent Adams wrote:
> way to the registered domain to see what it says."  

Right.  Just to be clear, if there were _no_ response here (i.e. a
NODATA response), then that has the same semantics as the "root
target" response: nobody else is in my policy authority realm.  But,

> "way.down.the.tree.org", I would know that the answer is at "tree.org".

yes, this is exactly right.
 
> weening myself off of the public suffix list.

No, it's not a bastardization at all: it's _exactly_ what I'm trying
to accomplish.  (And now you can see why I thought that example.com to
example.net was just a free extra feature, though I see now with your
help why it is problematic.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 23:26:55 -0400

> don't know how far up the tree to make that second query.

In order for that to be defined, you put a SOPA record at
foo.bar.example.com that says "example.com".  If you have no SOPA
record, the policy for foo.bar.example.com is "nobody else shares
this".  This is a "default closed" policy, which I think has to be the
right one.  

There's something slightly awkward about this for the CA case,
however, when you have deep trees and you want a wildcard cert that
descends the tree from example.com.  I'm still not sure what to do
about that, because it's going to be impossible to enumerate all the
names under a wildcard (and anyway, you can't do multi-label
wildcards).  I remain a little unhappy about this, but it strikes me
that anyone doing wildcard certs for deep trees may be in a world of
hurt anyway, and it would be better to add an additional SOPA record
for (for instance) *.oneIactuallyWant.example.com.

> everyone; I only want to ask at most two questions.

As long as you have the pointer up the tree, that should work.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 13 Mar 2013 04:41:00 +0000

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Tuesday, March 12, 2013 11:27 PM
> Subject: Re: [apps-discuss] "finding registered domains"
> 
> > exists) in the absence of a foo.bar.example.com policy.  The problem
> > is I don't know how far up the tree to make that second query.
> 
> foo.bar.example.com that says "example.com".  If you have no SOPA record,
> the policy for foo.bar.example.com is "nobody else shares this".  This is a
> "default closed" policy, which I think has to be the right one.
> 

I'm trying to wrap my head around this for the use case for domain trees such as example.co.uk. We know (or should know) that the (or at least one important) cut is always going to be at .co.uk. I think this is one of the use cases that has been problematic. Do we really want to rely on each subdomain up the tree publishing a SOPA record for this type of case? What do we do when some subdomains publish and others do not? Is the intent to force domain administrators to go along by them ending up with suboptimal outcomes if they don't?

I'm not asking these things to be snarky - I'm really not clear on the thinking here. In the email authentication space we've always gone to some lengths to avoid imposing new standards (SPF, DKIM, DMARC) on folks that don't really care to participate. I'm also concerned because my experience is that so many admins/domain owners get even the simplest DNS records wrong in implementation.

> There's something slightly awkward about this for the CA case, however,
> when you have deep trees and you want a wildcard cert that descends the
> tree from example.com.  I'm still not sure what to do about that, because it's
> going to be impossible to enumerate all the names under a wildcard (and
> anyway, you can't do multi-label wildcards).  I remain a little unhappy about
> this, but it strikes me that anyone doing wildcard certs for deep trees may be
> in a world of hurt anyway, and it would be better to add an additional SOPA
> record for (for instance) *.oneIactuallyWant.example.com.
> 
> > So in my case I explicitly will believe the
> > parent/grandparent/whatever statement, but I don't know how far up to
> > go, and I don't want to ask everyone; I only want to ask at most two
> questions.
> 

Mike

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 13 Mar 2013 19:41:02 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 10, 2013 12:22 PM
Subject: [apps-discuss] "finding registered domains"

...
>    1.  Do people think this is work that needs to be done?

I am still not very clear about what the problem is and what the possilbe solution is.

 Could you kindly summarize it in one or two sentences ?

Jiankang Yao

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Mar 2013 10:07:45 -0400

> I'm not asking these things to be snarky - I'm really not clear on the thinking here. In the email authentication space we've always gone to some lengths to avoid imposing new standards (SPF, DKIM,…

That is why I am concentrating on getting the new TLDs issued by ICANN
to publish records that say 'this is a public delegation point' that
would be used as input to prefix lists. That has a plausible
deployment model.

The way I would word this problem is that any protocol that depends on
more than 5% of parties to deploy before it provides value is doomed
and to be successful it probably needs to provide value at a much
lower deployment.

>> record for (for instance) *.oneIactuallyWant.example.com.

Wildcards are only one reason that CAs use the public prefix list.
Obviously a wildcard certificate for *.co.uk would be undesirable.

Mere presence of a DNS record is not going to cause a CA to
automatically change their policy on *.co.uk wildcards. But
publication of a record might well cause an exception to be signaled
for human administrator review.

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 14:43:21 -0000

> Could you kindly summarize it in one or two sentences ?

I agree that use cases would help a lot.  The ones I'm aware of are:

* Web cookies: limit how high up the DNS tree a site can promote its cookies.

* DMARC and other mail authentication: find policy documents for a
domain given one of its subdomains

* SSL/TLS certificates: prevent certificate issue for names at or above public
delegation points

* Variants: state that two parallel names are under the same management (has
issues different from the previous three)

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Mar 2013 13:20:42 -0400

> I agree that use cases would help a lot.  The ones I'm aware of are:

+1

The presentation of the information in DNS terms is trivial. The whole
problem is knowing what information to present and why.

> * Web cookies: limit how high up the DNS tree a site can promote its cookies.

Also prevent cookie sharing across subtrees, especially to reduce
cross site contamination issues when some parts of a tree are
outsourced.

HTTP is not the only protocol with cookies. There are application
level cookies as well. Rule 81 applies here and probably provides
grounds for a corollary.

So if I outsource management of my shopping cart to a payment
processor and my Web site to a cheap hosting service I probably don't
want cookies set on one to be visible on the other.

My view is that anything more complex than defining a domain subtree
as a distinct administrative region from all others is going to be too
complex to implement securely.

> * SSL/TLS certificates: prevent certificate issue for names at or above public

Actually VeriSign would be perfectly entitled to obtain an SSL
certificate off a public root for .com

What would be *BAD* would be *.com

The use made of the public suffix list is rather more however. If
someone is applying for a.b.c.d.e.f.g.h.i.example.com it probably does
not have an email server on it. It might even be an appliance that
does not have SMTP capability. Sending an email to check ownership of
the domain is not going to work. The email would have to go to
[email-masked].

Regardless of what the DNS mythology claims, the DNS administrator of
example.com has complete control over the subtree beneath it. That is
how the DNS is designed. If the owner of a.b.c.d.e.f.g.h.i.example.com
wants independence from example.com they have only one route and that
is to buy a domain of their own.

So while there are other applications where you might want to treat
different parts of the subtree as independent administrative domains
(ai.mit.edu might not want to share cookies with lcs.mit.edu) that is
not the case for CAs.

> issues different from the previous three)

That would be an interesting and useful problem but I really don't
want to commit to going down that rathole. That looks to me like
something that might suggest that we need to think about an extensible
approach.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Mar 2013 13:50:46 -0400

On Wed, Mar 13, 2013 at 04:41:00AM +0000, MH Michael Hammer (5304) wrote:
> > 
> 
> this is one of the use cases that has been problematic. Do we really
> want to rely on each subdomain up the tree publishing a SOPA record
> for this type of case? 

No, of course not.  Nominet puts a SOPA record with the root target at
co.uk.  That means, "This name does not share its administrative realm
with any other name," which is correct.  Nobody else needs to publish
anything for that to take effect.

It's only when you want to make positive association between two
different names that you need to have records at both sides.

> and others do not? Is the intent to force domain administrators to
> go along by them ending up with suboptimal outcomes if they don't?

No, the intent is to pick the safest possible state ("no shared
administrative realm") as the default, and to require positive action
if you want an association with other names.  I think Brad's point
about siblings is that the approach I'm arguing for breaks a current
expectation many people have -- that all the siblings are "safe".  But
that was always a dangerous arrangement, and I think it is becoming
more dangerous over time.

> I'm not asking these things to be snarky 

I didn't take it that way.  I think the proposal I'm making needs
plenty of examination and prodding.  I appreciate the comments and
questions.  Thanks.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Mar 2013 13:55:53 -0400

> and to be successful it probably needs to provide value at a much

I think the proposal I offer needs no more work by anyone tht your
proposal, and its deployment costs are exactly the same.  The only
difference between them is that the proposal I've made covers more
cases because it doesn't depend on the dodgy "public delegation point"
notion.  That's not the problem you have.  For instance, my employer
(Dyn) operates a service in dyndns.org that accepts host names from
customers and puts them in a zone.  There is no delegation.  Yet
almost every name in the dyndns.org zone is in a different
administrative realm.  If SOPA existed, we could signal this by
putting a SOPA record with the root target at dyndns.org.  None of our
customers would need to do anything.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Hugo Salgado <[email-masked]>
Date: Wed, 13 Mar 2013 14:56:59 -0300

> issues different from the previous three)

Also from Firefox browser:

* domain highlighting in the URL bar

* restricting the setting of the document.domain property (DOM
  same-origin policy)

Hugo

---

From: Behnam Esfahbod <[email-masked]>
Date: Wed, 13 Mar 2013 14:29:50 -0400

Andrew,

Reading the draft, I couldn't find any definition/description of what an
"administrative realm" or "authority" is. You are trying to address all the
issues listed here (cookies, DN highlighting, etc) but it is not obvious to
me why these all could/should be treated the same way.

For example, company Example may wants to prevent cookie sharing between
its domain (example.com) and their outsourced shopping subdomain (
shop.example.com), but likes to keep the address-bar domain-name
highlighting to "example.com", because of marketing reasons.

So, are you suggesting that there should be one administrative/authority
aspect for domain name hierarchy and the applications SHOULD adopt to this
assumption and behave similarly in different aspects of domain name
hierarchy (again, cookies, DN highlighting, etc)?

Thanks,
-Behnam

-- 
Behnam Esfahbod | بهنام اسفهبد
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 13 Mar 2013 18:56:47 +0000

...
> Just to be careful here, no matter _what_ we do, we are describing an arbitrary
> overlay topology of administrative trust relationships.
> That is necessarily true, because the relationships that currently exist in the
> DNS are DNS-topological only.  People are _used_ to the idea that names are
> related to one another in particular ways, and as a cultural fact that is mostly
> true; but in the not very distant past, it wasn't, and there's reason to suppose it
> might not obtain in the near future.

[Hill, Brad] Well, I meant to respect the basic structure as a tree that (mostly) directly encodes only ancestor / descendant relationships, rather than arbitrary cross-linkages across different branches.  (CNAME notwithstanding) As a matter of how the DNS works, and how it will continue to work for things like DNSSEC, the DNS admin of a given label has control of descendant labels.  The hierarchy of control is more than just implied.

...

> > 4) I am also concerned with mixing the state of siblings as to whether
> > they share an administrative relationship with the parent or not.
> > Whether the depth in the DNS hierarchy is a "real" thing or not, it
> > has been treated as such and been a part of the web security model for
> > almost 20 years.  The "walk towards the root until you find a
> > boundary, and all siblings are equal" procedures apply not just for
> > setting cookies, but to core JavaScript and therefore the Same Origin
> > Policy through a feature known as "domain lowering".
> 
> I take very seriously the argument that there is an existing and widely-deployed
> model.  I note, however, that the widely-deployed model is about to be thrown
> out anyway, regardless of how we feel about it.  For a significant number of the
> new TLDs are so-called ".brand" TLDs, and I'm pretty sure that the operators of
> .megacorp are going to want to be able to set shared cookies in
> www.megacorp and product1.megacorp and so on.
> 
> behaviour the default.  The wildcard trick was intended to make that easy, but
> I'm not perfectly sure it will.
> 

Allowing cookies or document.domain to be lowered to a gTLD controlled by a single entity is not quite "throwing out" the current model, it is just changing the depth of the hard stop - the algorithm and basic model otherwise remains totally intact.  In contrast, changes differentiate domain lowering properties among siblings at the same depth are a much more substantial change to how the Web security model works and increases the complexity of the algorithms and implementations, the mental model for users, and the complexity and size of the data needed to support that model. 

-Brad

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 13 Mar 2013 19:46:43 +0000

> On Behalf Of Hugo Salgado
> Sent: Wednesday, March 13, 2013 1:57 PM
> > * SSL/TLS certificates: prevent certificate issue for names at or
> > above public delegation points
> >
> > * Variants: state that two parallel names are under the same
> > management (has issues different from the previous three)
> 

[Hill, Brad] And possibly HSTS and Public Key Pinning with includeSubDomains flag set.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 16:04:13 -0400

> issues different from the previous three)

I'd like _not_ to include this as a target.  I can see how this trick
could be abused to help that problem, but the discussion upthread
about cross-domain linkages and the potential for load in the DNS
suggests to me that this is the wrong mechanism.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 16:07:44 -0400

> is to buy a domain of their own.

Well, yes and no.

The administrator of example.com has complete control over the subtree
beneath in the sense that s/he can either create names underneath,
_or_ can delegate beneath, _or_ can delete the delegation.  But if the
administrator of example.com delegates away h.i.example.com, s/he has
no control over what goes inside h.i.example.com.

It's trivially true that any name has control of the delegations
beneath it.  But I don't see how it's relevant.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 16:14:22 -0400

On Wed, Mar 13, 2013 at 06:56:47PM +0000, Hill, Brad wrote:
> 
> admin of a given label has control of descendant labels.  The
> hierarchy of control is more than just implied.
> 

This hierarchy is a straight artifact of the hierarchical name space.  So
yes, but once you've performed delegation you can't control what
happens on the other side of the zone cut (except by removing the
delegation).  Or, of course, maybe you can: maybe you're the same
organization.  This is sort of the point of what we're trying to do:
there's no way to read that distinction from the DNS today.
 
> algorithm and basic model otherwise remains totally intact.  In
> contrast, changes differentiate domain lowering properties among
> siblings at the same depth are a much more substantial change to how
> the Web security model works and increases the complexity of the
> algorithms and implementations, the mental model for users, and the
> complexity and size of the data needed to support that model.

Well, yes, but people are doing this anyway, with really lousy
security now.  So it feels to me like we need to support it, even if
we put in a deployment note making observations about what the
experience might be particularly during early deployment.  And after
all, it is entirely possible to support the present model of operation
in the approach I've outlined.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 16:17:33 -0400

> highlighting to "example.com", because of marketing reasons.

This is an interesting point.  It seems to me, however, that the whole
point of the address bar name highlighting is supposed to be for the
_user_, and to tell that user its scope.  That makes me think that the
answer here is, "Example loses." 

But the broader question is, "Is it sensible for a given name to have
different administrative realms for different purposes?"  If so, not
to put too fine a point on it, I think we're screwed.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Mar 2013 12:39:25 -0400

On Wed, Mar 13, 2013 at 02:43:21PM -0000,
 John Levine <[email-masked]> wrote 

> I agree that use cases would help a lot.  The ones I'm aware of are:

Also (from actual experience at a TLD registry with both 2nd-level and
3rd-level registrations):

Finding the guy in charge of a name. Two subcases:

* A X.509 CA receives a request to authenticate
www.foobar.asso.fr. Should it send the confirmation email to the
holder of asso.fr or to the holder of foobar.asso.fr?

* www.foobar.asso.fr hosts a phishing site. Should we write to
[email-masked] or to [email-masked]?

That's why I support the idea of doing something to solve this
problem. (And I volunteer to review.)

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2013 16:24:13 -0400

> [email-masked] or to [email-masked]?

Those look to me basically the same as finding the highest name in the 
tree under the same management.  The next step of getting the contact 
info is WEIRDS' department.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

PS: That second scenario is why I run abuse.net.  It would be nice if I 
didn't have to any more.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Mar 2013 17:56:53 -0400

> I agree that use cases would help a lot.  The ones I'm aware of are:

Another one I had at $DAYJOB: we make statistics about the "most
frequently requested" domains on our authoritative name servers. Of
course, we want foo.bar.example.fr and machin.example.fr to be counted
both as "example.fr". Some DNS statistics program (like DSC) do it
blindly, just by the number of labels. But .fr delegates both at the
2nd and 3rd level (gouv.fr, asso.fr, tm.fr...). We had to use Mozilla
Public Suffix List (via the excellent
<http://www.dkim-reputation.org/regdom-libs/>) for that (for .fr, we
know the registration rules and could have hardwired them, but the
program had to work for other TLD).

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2013 18:16:17 -0400

> program had to work for other TLD).

If you're running an authoritative server, you're mostly handing out 
referrals, so you know exactly where the delegations are.  Why don't you 
have your statistics programs report what the servers actually did?

Regards,