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

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: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Andrew Sullivan
> Sent: Saturday, March 09, 2013 11:23 PM
> To: apps-discuss@ietf.org
> 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.
> 
> 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
> ajs@anvilwalrusden.com
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss