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

Patrik Fältström <paf@frobbit.se> Sun, 10 March 2013 08:09 UTC

Return-Path: <paf@frobbit.se>
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 645EE21F8618 for <apps-discuss@ietfa.amsl.com>; Sun, 10 Mar 2013 00:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 ZtApkCON79Ok for <apps-discuss@ietfa.amsl.com>; Sun, 10 Mar 2013 00:09:23 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB321F8266 for <apps-discuss@ietf.org>; Sun, 10 Mar 2013 00:09:23 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id 322081FE1E; Sun, 10 Mar 2013 09:09:22 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <20130310042250.GE33497@mx1.yitter.info>
Date: Sun, 10 Mar 2013 09:09:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se>
References: <20130310042250.GE33497@mx1.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1499)
Cc: apps-discuss@ietf.org
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: Sun, 10 Mar 2013 08:09:24 -0000

On 10 mar 2013, at 05:22, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

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