Re: [DNSOP] Public Suffix List

bert hubert <bert.hubert@netherlabs.nl> Mon, 09 June 2008 12:33 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DC528C0FA; Mon, 9 Jun 2008 05:33:57 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8080C3A6778 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 05:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Level:
X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, WEIRD_QUOTING=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBS3yuAhnVDX for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 05:33:52 -0700 (PDT)
Received: from outpost.ds9a.nl (outpost.ds9a.nl [85.17.220.215]) by core3.amsl.com (Postfix) with ESMTP id 6EA913A6C54 for <dnsop@ietf.org>; Mon, 9 Jun 2008 05:33:52 -0700 (PDT)
Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BC2944574; Mon, 9 Jun 2008 14:34:23 +0200 (CEST)
Date: Mon, 09 Jun 2008 14:34:23 +0200
From: bert hubert <bert.hubert@netherlabs.nl>
To: Antoin Verschuren <Antoin.Verschuren@sidn.nl>
Message-ID: <20080609123423.GD15706@outpost.ds9a.nl>
Mail-Followup-To: bert hubert <bert.hubert@netherlabs.nl>, Antoin Verschuren <Antoin.Verschuren@sidn.nl>, dnsop@ietf.org, ietf-http-wg@w3.org
References: <484CFF47.1050106@mozilla.org> <484D1533.4060300@spaghetti.zurich.ibm.com> <B33086268D53A0429A3AA2774C83892C028E1694@KAEVS1.SIDN.local> <20080609121146.GC15706@outpost.ds9a.nl> <B33086268D53A0429A3AA2774C83892C028E1696@KAEVS1.SIDN.local>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <B33086268D53A0429A3AA2774C83892C028E1696@KAEVS1.SIDN.local>
User-Agent: Mutt/1.5.9i
Cc: dnsop@ietf.org, ietf-http-wg@w3.org
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

On Mon, Jun 09, 2008 at 02:24:30PM +0200, Antoin Verschuren wrote:
> > You can't hijack something that does not exist though, which is what I
> > think
> > is the problem here.
> 
> Agree, but when this global list of local DNS policy would exist and used, which would be authoritative, the list or the DNS ? 

The DNS of course. Compare whois for example - that is also
'non-authoritative' for real DNS lookups.

If I understand correctly, Mozilla wants to use this for security purposes:

  The usefulness of this can be seen if we take the example of cookies.
  Currently, browsers use an algorithm which basically only denies setting
  wide-ranging cookies for top-level domains with no dots (e.g. com or org).

  However, this does not work for top-level domains where only third-level
  registrations are allowed (e.g. .co.uk). In these cases, websites can set
  a cookie for .co.uk which will be passed onto every website registered
  under co.uk.

  Since there is no algorithmic method of finding the highest level at which
  a domain may be registered for a particular top-level domain (the policies
  differ with each registry), the only method is to create a list. This is
  the aim of the Public Suffix List.

  Software using the Public Suffix List will be able to detemine where
  cookies may and may not be set, protecting the user's data from theft.

So the instaflaming and ""technology"" jokes appear to be out of place. 

If "we" DNS people think we have a better way of encoding "public
delegations", we should move quickly to make that happen. In the meantime,
the public suffix list is probably a great idea.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop