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

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 08 Nov 2008 02:46:01 +0100

On Fri, 07 Nov 2008 21:51:47 +0100, Dean Anderson <[email-masked]> wrote:

> On Thu, 6 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA)  
> This is better.  But doesn't fix the underlying problem that breadth and
> scope of administrative control can't be determined by opera, or by
> anyone external to the administrative control.  And
> downloading/maintaining/controlling this file is another problem to
> manage.  Historically, this hasn't been found to be a very scalable
> solution.

Please see sec. 2 and 2.1 (use of HTTPS for retrieval, and digital  
signatures of content).

> Also, trying to have opera determine and distribute this information
> about what administrative domains there are on the internet is another
> serious problem. Not least of which, downloading the results of opera
> project's scanning is also a security concern.

Please see Appendix A (possible methods for collecting the information)

> If you mean to have a file determined by the admin domain itself, client
> and server need to authenticate and verify that file---with what
> certificate?  Who knows if the certificate offered is the __right__

Again, see sec 2 and appendix A. Actual information collection is outside  
the scope of the current version of this draft, because there are multiple  
methods; a separate specification will be needed for that part.

> certificate?  Only the user can figure that out. So you haven't made
> things any easier for the user; they STILL need to verify certificates.

Opera is already downloading root certificates from a digitally signed  
online repository using a secure connection, and the download is done in a  
fashion that the user will NOT be asked about certificates concerning that  
download. A dynamic download of the TLD structure information would be  
done in a similar manner, without user interaction.

>> 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.
>
> I'm not familiar with these proposed uses. But it would seem on the
> surface that they are solved by the same http/cookie change as I
> suggested.

I doubt that, they are needed in areas that are not using cookies, such as  
presentation of URL strings.

In any case: Google, Microsoft and Mozilla are ALL, right now, deploying  
browsers using Mozilla's PublicSuffix database, and two of them have been  
doing so for more than 6 months.

>> 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.
>
> That is a very subjective distinction. Who knows whether
> malicious.example.net is actually malicious?  'Malice' is a property
> that can't be determined by finite automata.  It cannot be done
> automatically. However, the security and trust aspect is easily handled
> by using SSL and teaching USERS how to properly verify the certificates.
> There is no way around that requirement; There are only two cases:  If
> the users don't verify trust properly, they can't ever be sure of the
> trusted authenticity of the server. If the users do verify properly,
> there is no way to fool them.

I suspect you misunderstand what the example is really about.

It is about a widely used spoofing attack against users.

An ordinary user would look at the beginning of the above hostname,  
"www.my-trusted-bank.com", and *ignore* the remainder of the name because  
they have been trained to look for that particular name, often missing the  
crucial part of a "/" being needed immediately afterwards. That is also  
what made http://[email-masked]/ such a nice tool for  
spoof stories until browsers made it much harder to use that method.

The result is that the user will believe they are on the trusted site, and  
may provide the site with important credentials.

The method used by Microsoft in IE8 Beta 1 (relased in March) is to  
highlight the real domain of the site, making it possible for an observant  
user to detect the discrepancy between what they expected their online  
location to be, and the reality.

It is not a complete solution, but it is part of what a browser can do to  
better inform the user, also on non-secure sites.

> without the interaction of the user.  You are merely trying to grapple
> the impossible, without realizing it is impossible.

Even if something is, strictly speaking, "impossible" (like calulating the  
exact numerical value of Pi), a good approximation (3.14159) will most  
often be sufficiently accurate for ordinary use, nor does it mean that we  
should not try to discover and use sufficiently good approximations.  
(Another example is IDNAbis)

Opera is currently using one approximation for cookie domain validation,  
using DNS, described in the "DNSCOOKIE" draft; Mozilla and PublicSuffix  
are probably using a much better approximation, information that can be  
used in the subTLD structure protocol.

IMO, an even better approximation to what our applications need for  
various automatic security features, would be a list of registry-like  
domains provided by the TLD regisitries.

If there are better approximations the DNSOp WG and other interested  
parties are encouraged to come forward with them.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 08 Nov 2008 02:46:01 +0100

-- 
Sincerely,
Yngve N. Pettersen

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Nov 2008 21:10:23 -0500 (EST)

On Sat, 8 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

> Opera is already downloading root certificates from a digitally signed online 
> repository using a secure connection, and the download is done in a fashion 
> that the user will NOT be asked about certificates concerning that download. 
> A dynamic download of the TLD structure information would be done in a 
> similar manner, without user interaction.

So in this case, Opera is creating and maintaining a list, and offering it
to their clients. Other software, including non-browser software, will
have to do the same. The problem is that if TLD's do not implement a
universal dicovery method, any fancy protocol will come to "someone is making
a list somewhere and you need to know this person and trust them". It also
scales poorly. See the non-standard scheme of naming the whois sides, and
software like 'jwhois' with a 32kb config file maintainer by "someone somewhere",
that requires updating all the time. We might as well stick sub-tld information
in /etc/jwhois.conf while we're at it - we don't need a new protocol for that.

That's why to me it would make more sense to have something like "tld.nic.<TLD>"
with information, either in DNS records that can be signed, or via some https
method with an SSL cer).

> doing so for more than 6 months.

So what will a new protocol add to this? The database will be required anyway,
because one does not know where to find this information for a random TLD.

> IMO, an even better approximation to what our applications need for various 
> automatic security features, would be a list of registry-like domains 
> provided by the TLD regisitries.

And probably the only common zone all Registry's reserved for themselves and
was not allowed to be users by Registrants is 'nic.TLD'.

> If there are better approximations the DNSOp WG and other interested parties 
> are encouraged to come forward with them.

the real problem is not the method of presenting or transfering the information,
the problem is finding it. Section 2 of this draft starts with:

 	The client retrieves the domain list for the Top Level Domain
 	"tld" from the vendor specified URI
 	https://tld-structure.example.com/tld/domainlist .

However, before that comes another unlisted step:

 	The client retrieves the meta information on where to
 	find the list of "TLD Structure" servers for each TLD from
 	some to be pre-determined location.

That's the problem not addressed in draft-pettersen-subtld-structure-04.txt

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Nov 2008 21:10:23 -0500 (EST)

Paul

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 08 Nov 2008 13:08:50 +0100

Hello Paul,

On Sat, 08 Nov 2008 03:10:23 +0100, Paul Wouters <[email-masked]>  
wrote:

>> online repository using a secure connection, and the download is done  
>> in a fashion that the user will NOT be asked about certificates  
>> concerning that download. A dynamic download of the TLD structure  
>> information would be done in a similar manner, without user interaction.
>

Which is what is currently happening, because the TLDs are not providing  
the information (in a machinereadable fashion, at least), and alternative  
discovery and database building methods (crowdsourcing) are being used.

> That's why to me it would make more sense to have something like  

Which is similar to what previous versions of the draft have suggested, a  
wellknown location specified by IANA.

Alternatively, the central repository can, for example, be hosted by IANA,  
and be open for vendors to mirror.

>> In any case: Google, Microsoft and Mozilla are ALL, right now,  
>> deploying browsers using Mozilla's PublicSuffix database, and two of  
>> them have been doing so for more than 6 months.
>

The protocol defines the format that can be used to distribute the data,  
not just from vendor to client, but from central repositories (however  
those are defined) to the vendor. It also specified the information  
provided (and can be expanded for future requirements).

My original thought was to have a central repository, accessed by all  
clients, although vendor hosted mirrors of such central repositories will  
work just as well, or better, but both types of arrangement requires, for  
ease of use, at least, that data are coded in a common format, reducing  
the need to convert between different representations.

> was not allowed to be users by Registrants is 'nic.TLD'.

As mentioned above, as common respository is an alternative.

>  	https://tld-structure.example.com/tld/domainlist .

That URL may be an opera.com, microsoft.com or mozilla.com URL, for  
example, or a central repsitory URL if somebody are willing to host a list  
for all clients.

> draft-pettersen-subtld-structure-04.txt

Previous versions of the draft did require an IANA specified URI to be  
used, and that the information had to be provided by the TLD regisitries.  
An archive copy is available at <URL:  
http://files.myopera.com/yngve/blog/draft-pettersen-subtld-structure-03.txt  

As I was starting to wonder if the requirement for information from  
registries might be holding the rest of the draft back, and with the  
emergence of Mozilla's PublicSuffix list (see Gerv's announcement and  
request for TLD registry assistance to this list earlier this year), I  
decided that it might be best to move the requirements for how to populate  
the database, and who should do it, out of the datafile format  
specification.

There are a couple of suggestions in Appendix A about how a database may  
be populated, and Appendix B mention a couple of alternative discovery  
methods that has been mentioned during the occasional discussions about  
this topic.

I have yet to start looking at how a specification for this should be  
formulated, but with PublicSuffix's database available, the need for such  
a specification may, perhaps, not be as immediate as it was. However, to  
be clear: I still think the original structure specification for each TLD  
should be provided by the registries, as they are AFAIK the ones with the  
best knowledge about their domain.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 08 Nov 2008 13:08:50 +0100

Hello Paul,

-- 
Sincerely,
Yngve N. Pettersen

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Nov 2008 12:50:22 -0500 (EST)

On Sat, 8 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

> emergence of Mozilla's PublicSuffix list (see Gerv's announcement and request 
> for TLD registry assistance to this list earlier this year), I decided that 
> it might be best to move the requirements for how to populate the database, 
> and who should do it, out of the datafile format specification.

Ah. understood. I guess it makes sense to limit the problem and at least
enroll this (unfindable) data in the same format everywhere.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Nov 2008 12:50:22 -0500 (EST)

Paul