Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Thu, 06 Nov 2008 21:51:24 +0100, Dean Anderson <[e-mail]> wrote:

>
>> The domain structure of a TLD is not something that changes frequently,  
>> it
>> is therefore suitable for a static file that contain the necessary
>> information, something which will also reduce network traffic.
>
> This static file is a bad idea waiting to not happen.  Root servers

Just assure you: By "static" I do not mean a file that won't change for  
the next 100 years. I mean "static" in the web service sense, as opposed  
to "dynamic" script generated content.

My suggestion in earlier versions of the draft have been that the client  
caches the received file for 30 days, then revalidate it, and that new  
registry-like domains should be included 90 days before going active.

This type of information is not updated frequently enough that a dynamic  
check for every domain is needed, nor is the number of domains a sizeable  
fraction of the domains registered, but small enough to make for a  
relatively small download every month or two. Nor is it likely to happen  
often (if ever) that a registry-like domain changes to an ordinary domain;  
it is more likely to be the other way around.

> I agree that the idea about figuring out tld substructure in order to
> determine cookie administration is also fatally flawed, for the reasons

Well, as I've mentiFrom [e-mail]  Thu Nov  6 14:09:15 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 90CA23A6825;
	Thu,  6 Nov 2008 14:09:15 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3FE2F3A6825
	for <[e-mail]>; Thu,  6 Nov 2008 14:09:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.269
X-Spam-Level: 
X-Spam-Status: No, score=-7.269 tagged_above=-999 required=5
	tests=[AWL=-0.670, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 uJZnT2gzDGiK for <[e-mail]>;
	Thu,  6 Nov 2008 14:09:12 -0800 (PST)
Received: from smtp.opera.com (sam.opera.com [213.236.208.81])
	by core3.amsl.com (Postfix) with ESMTP id B9B5B3A67AC
	for <[e-mail]>; Thu,  6 Nov 2008 14:09:11 -0800 (PST)
Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22])
	(authenticated bits=0)
	by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	mA6M8HA0004059
	(version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NOT);
	Thu, 6 Nov 2008 22:08:18 GMT
Date: Thu, 06 Nov 2008 23:08:11 +0100
To: "Dean Anderson" <[e-mail]>
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>
Organization: Opera Software AS
MIME-Version: 1.0
References: <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Opera Mail/9.26 (Win32)
Cc: George Barwood <[e-mail]>, [e-mail]
Subject: Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"; DelSp="yes"
Sender: [e-mail]
Errors-To: [e-mail]

On Thu, 06 Nov 2008 21:51:24 +0100, Dean Anderson <[e-mail]> wrote:

>
>> The domain structure of a TLD is not something that changes frequently,  
>> it
>> is therefore suitable for a static file that contain the necessary
>> information, something which will also reduce network traffic.
>
> This static file is a bad idea waiting to not happen.  Root servers

Just assure you: By "static" I do not mean a file that won't change for  
the next 100 years. I mean "static" in the web service sense, as opposed  
to "dynamic" script generated content.

My suggestion in earlier versions of the draft have been that the client  
caches the received file for 30 days, then revalidate it, and that new  
registry-like domains should be included 90 days before going active.

This type of information is not updated frequently enough that a dynamic  
check for every domain is needed, nor is the number of domains a sizeable  
fraction of the domains registered, but small enough to make for a  
relatively small download every month or two. Nor is it likely to happen  
often (if ever) that a registry-like domain changes to an ordinary domain;  
it is more likely to be the other way around.

> I agree that the idea about figuring out tld substructure in order to
> determine cookie administration is also fatally flawed, for the reasons

Well, as I've mentioned earlier, cookies is the area that have spurred my  
development of this specification. It is not the only area asking for such  
information, as I've also mentioned earlier, for example URL display in  
FF3 and IE8, and if I am not mistaken, Google Chrome. And there are likely  
more.

One area where developers want to use such information is to help users  
understand where they actually are on the Internet, for example when being  
directed somehow to  
"www.my-trusted-bank.com.foo.bar.and.something.else.malicious.example.net",  
by highlighting "malicious.example.net", and making the rest almost  
invisible.

> already described: There is no way to determine administrative control
> via DNS queries. Either case of same SOA or different SOA could mean
> same admin control or different admin control.

Better suggestions for discovering and/or adding the information we need,  
or better ways to solve the problems we are working on, will be welcomed.

> In order to limit access to cookies to its admin control, you need to
> change the cookie format, and probably encrypt the cookie data, and make
> changes to the HTTP protocol to make it clear what admin authority
> sourced the date, is requesting the data, and to what admin authorities
> the data can be provided.  It is impossible to infer this information
> from the information now available to the browser. Protocol and format
> changes are required.  DNS is the wrong place to look.

As mentioned earlier in this thread, I am also promoting an updated cookie  
specification. However, that is going to take a while to implement when  
the draft eventually have become an RFC.

However, what has helped cookies get to the marketcoverage they do have  
(just about every web site serving anything more advanced than static HTML  
files) is their ease of use. Write a spec that make them any more complex  
to use, and the spec will not get implemented, much less adopted by the  
market. My draft may actually be close to that edge because it requires  
the host to set the cookie for a subdomain in which the host's name is the  
suffix, making website deployment more difficult in some respects.

But, as mentioned, cookies is not the only area wanting this information.  
Not anymore.

So: Treat cookies as a usage example (it is included as a profile example  
in the draft; BTW I did consider, but decided against, releasing those two  
parts as separate documents), not the sole reason for the subtld draft's  
existence.


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


oned earlier, cookies is the area that have spurred my  
development of this specification. It is not the only area asking for such  
information, as I've also mentioned earlier, for example URL display in  
FF3 and IE8, and if I am not mistaken, Google Chrome. And there are likely  
more.

One area where developers want to use such information is to help users  
understand where they actually are on the Internet, for example when being  
directed somehow to  
"www.my-trusted-bank.com.foo.bar.and.something.else.malicious.example.net",  
by highlighting "malicious.example.net", and making the rest almost  
invisible.

> already described: There is no way to determine administrative control
> via DNS queries. Either case of same SOA or different SOA could mean
> same admin control or different admin control.

Better suggestions for discovering and/or adding the information we need,  
or better ways to solve the problems we are working on, will be welcomed.

> In order to limit access to cookies to its admin control, you need to
> change the cookie format, and probably encrypt the cookie data, and make
> changes to the HTTP protocol to make it clear what admin authority
> sourced the date, is requesting the data, and to what admin authorities
> the data can be provided.  It is impossible to infer this information
> from the information now available to the browser. Protocol and format
> changes are required.  DNS is the wrong place to look.

As mentioned earlier in this thread, I am also promoting an updated cookie  
specification. However, that is going to take a while to implement when  
the draft eventually have become an RFC.

However, what has helped cookies get to the marketcoverage they do have  
(just about every web site serving anything more advanced than static HTML  
files) is their ease of use. Write a spec that make them any more complex  
to use, and the spec will not get implemented, much less adopted by the  
market. My draft may actually be close to that edge because it requires  
the host to set the cookie for a subdomain in which the host's name is the  
suffix, making website deployment more difficult in some respects.

But, as mentioned, cookies is not the only area wanting this information.  
Not anymore.

So: Treat cookies as a usage example (it is included as a profile example  
in the draft; BTW I did consider, but decided against, releasing those two  
parts as separate documents), not the sole reason for the subtld draft's  
existence.


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop