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

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 12 March 2013 20:19 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD7E11E80F3 for <apps-discuss@ietfa.amsl.com>; Tue, 12 Mar 2013 13:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.518
X-Spam-Level:
X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_38=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asi5qPieB3fx for <apps-discuss@ietfa.amsl.com>; Tue, 12 Mar 2013 13:19:37 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B967B11E80E3 for <apps-discuss@ietf.org>; Tue, 12 Mar 2013 13:19:37 -0700 (PDT)
Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 354788A031 for <apps-discuss@ietf.org>; Tue, 12 Mar 2013 20:19:37 +0000 (UTC)
Date: Tue, 12 Mar 2013 16:19:15 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: apps-discuss@ietf.org
Message-ID: <20130312201915.GD41728@mx1.yitter.info>
References: <20130310042250.GE33497@mx1.yitter.info> <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [apps-discuss] "finding registered domains"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 20:19:38 -0000

Brad,

Thanks for your comments.  Some more questions inline below.

On Tue, Mar 12, 2013 at 02:23:18PM +0000, Hill, Brad wrote:

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

>   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

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
ajs@anvilwalrusden.com