Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Thu, Jun 12, 2008 at 09:47:36AM +0200, Antoin Verschuren [EMAIL PROTECTED] wrote a message of 33 lines which said: Perhaps it's time to move back to promoting Opera again. Are you sure that they do not do the same? I tried to promote Konqueror but it has apparently the same (or even worse) bug than Firefox. And my bug report for Konqueror was closed immediately, which seems to indicate that the Mozilla people are not the only one with deaf ears. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Are you sure that they do not do the same? I tried to promote Konqueror but it has apparently the same (or even worse) bug than Firefox. And my bug report for Konqueror was closed immediately, which seems to indicate that the Mozilla people are not the only one with deaf ears. Yes, but at least they consulted the IETF DNSOP WG, and not insulted them. It's for the layer 9 issue, not for the bad code. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E [EMAIL PROTECTED] W http://www.sidn.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Antoin Verschuren wrote: No. I don't need to sell you the idea. The idea doesn't stand or fall on the opinion of this mailing list. Did you really say this ? Did I read this correctly ? No, can't be. I don't think Mozilla wants to insult all the IETF experts that have voluntarily helped them make a living in the first place... Why is the above an insult? It's just a statement of fact. I didn't come here to say I have this idea. If you guys like it, we'll do it. If you don't like it, we won't. I apologise if some people thought that this is what I was saying. As I said, I came here because Yngve suggested that you would appreciate being told about this scheme. I've had some useful feedback, and food for thought. And I'm grateful to those people who gave it to me. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly [EMAIL PROTECTED] wrote: On 12 Jun 2008, at 12:25, Gervase Markham wrote: The second question is one of resources and client complexity. I am meeting resistance to the idea of having the existing list regularly dynamically downloaded, which would be the simplest method of providing more frequent updates than the six-to-eight week Firefox security releases. An assemble-and-cache-the-data-from-DNS scheme would be an order of magnitude more complex. I'm not sure why you would need to assemble anything. Couldn't you seize the data you need, on demand, from the DNS (and cache at will). DNS, or full DNS, is not always available. There are at least two scenarios where this is the case: - Behind (very) closed firewalls, where all access go through a HTTP-only proxy. No DNS for external addresses is available. For that matter, when going through a proxy you have no way of knowing if the DNS available to you know anything about the address space you are accessing through the proxy. - On a number of systems, in particular phone devices, the application does not even have access to DNS to do a name lookup, it must specify the hostname, and try to connect. Additionally, a DNS-only solution would mean implementing a DNS client inside the application, since AFAICT the platform socket APIs usually do not provide the necessary functionality needed to access non-IPaddress data. While I am not opposed to the data being available in DNS, there must be a simple way to collect and provide it to clients efficiently and for any use case, while reducing privacy issues (which a batch of data for a given TLD will solve neatly), and with respect to HTTP clients, HTTP is the only method we can rely on, and it will also be available to many specialized applications that use HTTP, perhaps through some library. -- Sincerely, Yngve N. Pettersen Senior Developer Email: [EMAIL PROTECTED] Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax:+47 24 16 40 01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 12, 2008, at 8:26 AM, Yngve Nysaeter Pettersen wrote: - Behind (very) closed firewalls, where all access go through a HTTP-only proxy. No DNS for external addresses is available. For that matter, when going through a proxy you have no way of knowing if the DNS available to you know anything about the address space you are accessing through the proxy. - On a number of systems, in particular phone devices, the application does not even have access to DNS to do a name lookup, it must specify the hostname, and try to connect. Ouch. That's really painful. For those devices I think you'd have to fall back to tunneling the DNS request over an HTTP channel. Additionally, a DNS-only solution would mean implementing a DNS client inside the application, since AFAICT the platform socket APIs usually do not provide the necessary functionality needed to access non-IPaddress data. I think Mozilla already has its own DNS resolver. It might need to be enhanced to support DNSSEC if it doesn't already. The ISC has a resolver you can use that's under the BSD license. The resolver isn't very big. So I think this is a non-issue. I can see why you're resisting doing it this way. It does make for more work. But what I'd be worried about if you *don't* do it this way is that you're going to wind up making a mistake in your static list that's not going to get corrected in time, and somebody's going to run into an issue that gets you dinged for another stupid security complaint. And even though it was the fault of the site that allowed the bogus cookie, you're still going to get all the bad publicity. With a just-in-time lazy lookup scheme, you can be much more responsive. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Thu, 12 Jun 2008 15:56:13 +0200, Ted Lemon [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 6:25 AM, Gervase Markham wrote: Is there a particular reason that DNS is a better mechanism than HTTP, in your view? Or is that an implementation detail? The DNS occurred to me because it's already used for carrying domain names, and also because I've been doing DNS for a long time, so it's a comfortable tool for me. HTTP would work as long as the queries were for specific domain names. However, you would miss taking advantage of all the work DNS server implementors have done to make DNS lookups really fast. Also, I suspect the overhead of an HTTP request is substantially higher than the overhead of a DNS request when you think about all the groovy headers that normally get stuffed into HTTP, particularly if you want to use SSL. With DNSSEC, the DNSSEC server signs a zone once and then just answers you with the signed data when you ask for it. Whereas with HTTPS the HTTP server has to re-sign the data for every query. The way I envision a dynamically updated system for this (see my draft), the information would be grouped for each TLD in a single file that the client downloads every 30 days when needed. That means that the overhead is kept to a minimum. Where the information in the file(s) comes from is a separate topic. It can be a database maintained somewhere, or it could be DNS (but in that case it would have to be traversable). -- Sincerely, Yngve N. Pettersen Senior Developer Email: [EMAIL PROTECTED] Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax:+47 24 16 40 01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Yngve Nysaeter Pettersen wrote: On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly [EMAIL PROTECTED] wrote: On 12 Jun 2008, at 12:25, Gervase Markham wrote: The second question is one of resources and client complexity. I am meeting resistance to the idea of having the existing list regularly dynamically downloaded, which would be the simplest method of providing more frequent updates than the six-to-eight week Firefox security releases. An assemble-and-cache-the-data-from-DNS scheme would be an order of magnitude more complex. I'm not sure why you would need to assemble anything. Couldn't you seize the data you need, on demand, from the DNS (and cache at will). DNS, or full DNS, is not always available. There are at least two scenarios where this is the case: - Behind (very) closed firewalls, where all access go through a HTTP-only proxy. No DNS for external addresses is available. For that matter, when going through a proxy you have no way of knowing if the DNS available to you know anything about the address space you are accessing through the proxy. - On a number of systems, in particular phone devices, the application does not even have access to DNS to do a name lookup, it must specify the hostname, and try to connect. A DNS-based solution does not *need* to be a DNS-*only* solution. As I understand it, your list associates suffixes with true/false state, i.e. whether they are public or not. Imagine a tree of subdomains, all of which exist only to provide true/false information, rooted at, say, suffix-list.mozilla.org. If a given subdomain exists, true, otherwise false. And for http-only scenarios, have each of these subdomains be a CNAME pointing a static web page, say true.suffix-lists.mozilla.org., which contains just the word True. Both the content of the pages, and the DNS entries, could be cached in their respective systems (web browser cache, or DNS resolver cache). Timeliness of updates would be maintained by appropriate mechanisms to tell the querying agent to check again (HTTP tag or DNS TTL). The HTTP side of things does not require a separate DNS client. But, the updates to the list can be made trivially by manipulation of DNS data alone, and use of DNS involves much less processing on the client side if DNS client querying is possible (one UDP packet, generally). Brian Additionally, a DNS-only solution would mean implementing a DNS client inside the application, since AFAICT the platform socket APIs usually do not provide the necessary functionality needed to access non-IPaddress data. While I am not opposed to the data being available in DNS, there must be a simple way to collect and provide it to clients efficiently and for any use case, while reducing privacy issues (which a batch of data for a given TLD will solve neatly), and with respect to HTTP clients, HTTP is the only method we can rely on, and it will also be available to many specialized applications that use HTTP, perhaps through some library. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Florian Weimer wrote: * Jamie Lokier: (By the way, although we're talking about administrative divides in the DNS tree, a little thought might be given to administrative divides in URL trees. There are a fair number of sites containing http://domain.com/user1/* and http://domain.com/user2/*, where those prefixes indicates separately administered URL spaces. Do similar cookie issues apply? Yes. I think Ebay suffers from these issues. Indeed. This is one of the reasons that livejournal switched from www.livejournal.com/name to name.livejournal.com. It prevented rogue code on user sites stealing the cookies of other users. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jelte Jansen wrote: won't they run into the very same problem if only tld's (and their sld's) are marked as don't-set-cookies-here? Or is livejournal.com also supposed to get on the list of public suffixes? No. They can set cookies for www.livejournal.com or admin.livejournal.com (as opposed to livejournal.com), and these will not be shared with name.livejournal.com. This is somewhat of a red herring; the problem they had is one they could fix using existing technology. It's not what the public suffix list addresses. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gervase Markham wrote: Florian Weimer wrote: * Jamie Lokier: Yes. I think Ebay suffers from these issues. Indeed. This is one of the reasons that livejournal switched from www.livejournal.com/name to name.livejournal.com. It prevented rogue code on user sites stealing the cookies of other users. won't they run into the very same problem if only tld's (and their sld's) are marked as don't-set-cookies-here? Or is livejournal.com also supposed to get on the list of public suffixes? And will they care? (well, livejournal might, but i could imagine some others not to care enough to get themselves on it) Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIT4+T4nZCKsdOncURAqZkAKCOxkwMs6By3zxef2AhKU7nP9+0qgCbBJZd sEApH+yga8r+DXQVN76qpMQ= =SP/N -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Wed, Jun 11, 2008 at 10:15:19AM +0100, Gervase Markham [EMAIL PROTECTED] wrote a message of 53 lines which said: Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? Interesting. It reminds me of the RIR which assign IP addresses prefixes without being able to guarantee they will be routed. I always assumed that the poor domain name registrant had only to fight with the rules of the registrar/registry/ICANN/governement to get his domain registered and used everywhere in the world. Now, I see that besides registration rules (sometimes painful, see http://www.afnic.fr/obtenir/chartes_en), registrants also have to go through the filter of browser authors. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Henrik Nordstrom wrote: I seriously question this will break part. Sure, they will get annoyed, but in nearly all possible solutions layering ontop of the existing cookie system there will be easy ways for the owners of such sites to make them behave well, and a transition period giving them inciative and reasonable warning period to do so. Other list participants were warning about the possibility of people abandoning Firefox in droves if there were cookie-related problems caused by its use of public suffix list. You, on the other hand, are suggesting that we can just make changes to the way cookies work and expect broken sites to fix themselves. These seem to be two irreconcilable views of the future. Long history and experience has shown us that we can't just break people's websites like that. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Paul Hoffman wrote: For your IDN display technology, Mozilla decides which TLDs have a responsible attitude. Mozilla enforces these rules as a powerful incentive for TLDs to do as Mozilla wishes. As are Microsoft's rules - which, sadly, are both different and IMO much more likely to retard the growth of IDN. But that's another discussion. In doing so, Mozilla degrades the user experience of TLDs that don't go along with the Mozilla rules, such as .com/.net and ccTLDs throughout the world. The Mozilla public suffix list may prove to be similar. The difference is that the public suffix list is an (attempt at an) expression of fact, not policy. If you are concerned that we will withhold changes or issue known-incorrect lists in order to conduct some sort of vendetta against a particular TLD, all I can say is why on earth would we do that? Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Dean Anderson wrote: That's unfortunate; but I must say this upset was not communicated to me. Probably that's because you are using SORBS to filter your email. SORBS has an unusually high number of false positives, and for example, falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You can find more information about SORBS on http://www.iadl.org/ No-one can have control over and knowledge of everything their ISP does with relation to the services they provide. I confess I've only ever vaguely heard the name SORBS, and had no idea that my provider was using it. But I don't believe that using it makes me uncontactable. My phone number and address are on my personal web page. I can hardly imagine some TLD administrator saying I'm so irritated about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty email. Hang on, my email's been rejected. Oh well, I guess I'll just have to live with it. That policy of ours should have no effect whatsoever on TLDs with a responsible attitude to homographs. Our registration requirements are not onerous. ??? This statement doesn't seem very credible. What authority do you have to decide what a 'responsible attitude to homegraphs' would be? What's your answer to that question? (Hint: the answer no-one is equivalent to the answer the registries, which has been shown not to work. See http://www.shmoo.com/idn/ .) Mozilla.org doesn't represent the internet industry nor any government or governing organization. No, we represent our users, and we make all sorts of security decisions for them on a regular basis. One of the reasons Firefox is popular is precisely because it doesn't wimp out of security decisions with user-irritating popup questions they have no information to answer. But, as someone else has said, if people don't like the decisions we make, they can either become part of we and seek to change them, or they can change or build their copy, or can distribute an alternative browser. Why should TLD's think they need to register with Mozilla.org? They don't have to. Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Florian Weimer wrote: Have a look at this file: /usr/share/apps/khtml/domain_info Indeed. It looks like they do the same thing as us, but in a far more approximate and erroneous fashion. Persuading them to use the public suffix list would be an improvement. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Tue, Jun 10, 2008 at 11:31:00PM +0200, Stephane Bortzmeyer [EMAIL PROTECTED] wrote a message of 16 lines which said: I assume it is a list of TLD which register at the third level. If so, it is questionable (.af, .dz, .fr register at the second and the third level and I do not know how Konqueror handles it). Reported http://bugs.kde.org/show_bug.cgi?id=163774. Let's see if Konqueror people react in the Mozilla way (We decided and your opinion does not matter) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On ons, 2008-06-11 at 10:10 +0100, Gervase Markham wrote: Other list participants were warning about the possibility of people abandoning Firefox in droves if there were cookie-related problems caused by its use of public suffix list. If you do this wronly yes. You, on the other hand, are suggesting that we can just make changes to the way cookies work and expect broken sites to fix themselves. These seem to be two irreconcilable views of the future. No. Neither users or sites are completely static in nature. Long history and experience has shown us that we can't just break people's websites like that. Sites do break in upgrades. Problems arise if you break too many of them and neither the site operators of users have an easy way around, or when they do not understand why things broke. Fortunately the area we are discussing is fundamentally broken by design, and sites do break today differently in different browsers. If you want something positive to come out of discussions like this you have to have a little more open mind in looking where to find solutions. There is at least 10 different solutions to the cookie domain problem, of varying complexity and feasibility. Your proposed list is one, and not a competely bad one, but very incomplete and too static to be feasible as the solution to this problem. But it's a reasonable interim step to patch things up while discussing how the actual problem should be addressed. In short the cookie problem is threefold: a) Receivers of a cookie have no way of knowing who issued that cookie. b) Receivers of cookies have no means of indicating who is allowed to set cookies for them. c) Issuers of cookies often want to issue a cookie to multiple domains all of which is under their administrative control, but often have to figth the very blunt domain based filters. As result we have many designs using URL based transfer of the cookie details when moving from one site to another when better operation would be seen if the cookie could be managed as a single cookie valid for multiple sites. These URL based cookie tunnels is often installed as a way around broken browser cookie policies, and I would suspect they often create gaping security issues from lacking awareness of why these policies even exists. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Tue, Jun 10, 2008 at 09:22:27PM +0200, Florian Weimer [EMAIL PROTECTED] wrote a message of 10 lines which said: In other words, Internet Explorer has got it's own list (and the operating system, too, for use in DNS devolution). According to this blog post, IE does it the other direction (SLD are the rule and registration under the TLD the exception): http://crisp.tweakblogs.net/blog/ie-and-2-letter-domain-names.html ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: * We, mozilla, obviously can't do this ourselves On the contrary. We have done it for ourselves. so you must do it for us or else negative things will happen (and you'll be at fault, not us, mozilla). Please continue to do this work for us till the end of time. Oh, and we need it immediately. We don't need it immediately. The first Firefox 3 security release will probably be in six to eight weeks. * We, mozilla, won't work on any other solution because we don't think it'll work or it'll take too much effort and we refuse to help out in those ventures even if they might be better. Please stop talking about alternatives as we don't want your opinions on them. It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: * We, mozilla, obviously can't do this ourselves On the contrary. We have done it for ourselves. so you must do it for us or else negative things will happen (and you'll be at fault, not us, mozilla). Please continue to do this work for us till the end of time. Oh, and we need it immediately. We don't need it immediately. The first Firefox 3 security release will probably be in six to eight weeks. * We, mozilla, won't work on any other solution because we don't think it'll work or it'll take too much effort and we refuse to help out in those ventures even if they might be better. Please stop talking about alternatives as we don't want your opinions on them. It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jeroen Massar wrote: If adserver.co.uk (as they are 'evil') sets a cookie for co.uk then indeed that cookie gets sent to mybank.co.uk too. What harm does/can this do? (Except that they might set a cookie identical of type to the bank one and maybe auto-login to their bank account!?) sigh Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk, mypetstore.co.uk to supply them with ads. adserver.co.uk can set the ad-tracking cookie for .co.uk and build up a cross-site profile of a particular user, perhaps augmented by information passed to them by one or more of the sites concerned. This is a privacy issue. Therefore, they should not be permitted to set such cookies. The only way to do that, while continuing to allow foo.com to set cookies, is for the browser to know the difference between co.uk and foo.com. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: Jeroen Massar wrote: If adserver.co.uk (as they are 'evil') sets a cookie for co.uk then indeed that cookie gets sent to mybank.co.uk too. What harm does/can this do? (Except that they might set a cookie identical of type to the bank one and maybe auto-login to their bank account!?) sigh Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk, mypetstore.co.uk to supply them with ads. adserver.co.uk can set the ad-tracking cookie for .co.uk and build up a cross-site profile of a particular user, perhaps augmented by information passed to them by one or more of the sites concerned. This is a privacy issue. Therefore, they should not be permitted to set such cookies. The only way to do that, while continuing to allow foo.com to set cookies, is for the browser to know the difference between co.uk and foo.com. Thus you are going to break the contract that mybank.co.uk has with adserver.co.uk? wow, now you are really getting into something... That privacy issue is not a privacy issue, that is an issue with the bank in question which is compromising the privacy of its users. Solve the problem at the bank. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
While this thread isn't necessarily off-topic for ietf-http-wg list, it's more relevant IMO to dnsop, and cross-posted high-volume discussions tend to be distracting. So, please try to move discussion onto the dnsop list (I've set Reply- To accordingly). Thanks, -- Mark Nottingham http://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
At 23:10 +1000 6/11/08, Mark Nottingham wrote: While this thread isn't necessarily off-topic for ietf-http-wg list, it's more relevant IMO to dnsop, and cross-posted high-volume discussions tend to be distracting. So, please try to move discussion onto the dnsop list (I've set Reply- To accordingly). Odd to see this, I was about to say what does this have to do with DNS operations? and suggest that it move back to the HTTP group. Cookies aren't part of the DNS protocol. Is the issue that a cookie needs to state for what domains it is valid? Are you trying to relate domain names to a registrant? That's not a DNS issue, that's a WhoIs/IRIS issue, if you want to pin that into a protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: Oh? How is this reconciled with earlier comments that login.mybank.co.uk and accounts.mybank.co.uk are grouped together - or is the Public Suffix List only for history grouping in browsers, not for cookie sharing? under the current code ... www.mybank.co.uk can set cookies for ... co.uk (shared with adserver.co.uk but not with myorg.org.uk). It is this latter use we want to prevent. We can do so by stopping cookies being set for any domain which is a public suffix. I'm not seeing how this is different from mybank.livejournal.com setting cookies on livejournal.com which can be read by adserver.livejournal.com. livejournal.com needs to be on your Public Suffix List to prevent that - if the content from subdomains can set their own cookies. Maybe not on Livejournal, but there are sites where it's possible. Even in mybank.co.uk, it's typical that login.mybank.co.uk and thirdpartyinformation.mybank.co.uk will be somewhat independent. The latter should not be setting arbitrary cookies affecting the former, imho - security, rather than privacy. Regarding the break the contract with adserver argument, there are plenty of ways for mybank.co.uk to pass tracking info to adserver.co.uk by contract. Banning cross-domain cookies in this case just forces them to use another method. (Again, I comment that cookies are not the only way we are using this information.) I don't think anybody minds how you use the information to present History dialogs and such. Just whether it breaks applications that come to depend on the structure of the list, and whether it adds another barrier for site publishers who serve public content in a way which resembles NICs. -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Edward Lewis wrote: Is the issue that a cookie needs to state for what domains it is valid? No. Are you trying to relate domain names to a registrant? No. I must confess it is somewhat frustrating when, having put up a website explaining what this is all about, and having had a long discussion on this list, people continually misunderstand the point while having shown no evidence of attempting to read the existing explanations. I even got one (private) mail basically saying I can't be bothered to read all that. Tell me, what are you trying to do? http://publicsuffix/learn/ has more info (and I've just checked in another update, which should be visible in the next day or so. There's a human in the update loop). Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
http://publicsuffix/learn/ has more info (and I've just checked in another update, which should be visible in the next day or so. There's a human in the update loop). Gerv ___ that URL does not resolve in the way you might expect. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
[EMAIL PROTECTED] wrote: that URL does not resolve in the way you might expect. Sorry :-) Cut and pasted from my browser without checking. That's my local testing copy, of course. http://www.publicsuffix.org/learn/ Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote: It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. Putting the list in the DNS instead of in the browser isn't workable? Serious question. I think several proposals have been advanced here that /could/ work. Mine has the virtue of being completely under your control. The other one, where subdomains are called out in the zones of the domains that contain them, is not under your control, and wouldn't be a good interim solution, but sounds like a good long-term solution because it puts correctness in the hands of the people who suffer or benefit from it. So what I would personally like to see here is a staged transition. In the first stage, mozilla.org would set up a TLD list in its own DNS space, or in some new subdomain they register with good anycast replication so that no individual server has to bear the entire load. This list would be maintained by mozilla.org, using information from registries and domain owners, and also using your current ad-hoc system. But you'd also implement the system that was proposed here where the registries themselves can publish this information in their own domains. And over time, the hope would be that the number of TLDs you'd have to maintain in your list would slowly dwindle, to the point where it would become more of a quirks list than a registry of its own. This could work because the incentives are in the right direction - sites that have problems with your ad-hoc registry can either contact you or fix their own DNS, and fixing their own DNS may well be easier. I haven't heard you responding that either of these solutions wouldn't work, so I'm assuming they would, but perhaps I'm wrong. It also may be the case that for reasons of practicality you need to start with a list embedded in the browser; as long as you have a plan to make the transition to a list that's maintained more dynamically, and as long as you actually execute that plan, it seems to me that this is harmless. BTW, thanks for your reasoned responses to all these questions and accusations being thrown at you. You seem to have really elicited a lot of energetic response with your initial request, and I hope that something good will come of it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Jun 11, 2008, at 11:06 AM, Joe Baptista wrote: Listening would you mind explaining something here. Do we work for you? I'm pretty sure your being paid to promote your public suffix idea but we are not. There are many here who are too busy to spend time reading your stuff, let alone go back to the web site for updates. Joe, the problem description on the web site contains five paragraphs, two of which are a single sentence. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Joe Baptista wrote: Listening would you mind explaining something here. Do we work for you? I'm pretty sure your being paid to promote your public suffix idea but we are not. There are many here who are too busy to spend time reading your stuff, let alone go back to the web site for updates. That's fine. But please don't ask me questions about it then. - I don't have time to understand this. - Fine. - I do have time to understand this. Here is an intelligent question. - Fine. - I don't have time to understand this so I'm going to ask uninformed questions. - Not fine. Not just here, but in any walk of life where people respect other people's time. Now Gerv focus. You have come here for a reason and that is to promote a protocol. No. I came here because Yngve suggested that the membership of this list would appreciate a heads-up. Gerv focus. Kindly remember your position in his affair. You are here on behalf Mozilla to sell an idea and we are the people who have to be sold. No. I don't need to sell you the idea. The idea doesn't stand or fall on the opinion of this mailing list. Incidentally - have you answered by question yet - or put it on the web site? What happens to your web browsers behavior if I try to surf a TLD not on the list? I've answered it once to you privately and once to the list. Third time: the same thing as now. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
Joe Baptista wrote: Listening would you mind explaining something here. Do we work for you? I'm pretty sure your being paid to promote your public suffix idea but we are not. There are many here who are too busy to spend time reading your stuff, let alone go back to the web site for updates. That's fine. But please don't ask me questions about it then. - I don't have time to understand this. - Fine. - I do have time to understand this. Here is an intelligent question. - Fine. - I don't have time to understand this so I'm going to ask uninformed questions. - Not fine. Not just here, but in any walk of life where people respect other people's time. Now Gerv focus. You have come here for a reason and that is to promote a protocol. No. I came here because Yngve suggested that the membership of this list would appreciate a heads-up. Gerv focus. Kindly remember your position in his affair. You are here on behalf Mozilla to sell an idea and we are the people who have to be sold. No. I don't need to sell you the idea. The idea doesn't stand or fall on the opinion of this mailing list. Incidentally - have you answered by question yet - or put it on the web site? What happens to your web browsers behavior if I try to surf a TLD not on the list? I've answered it once to you privately and once to the list. Third time: the same thing as now. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: The difference is that the public suffix list is an (attempt at an) expression of fact, not policy. I think is where you are encountering resistance, even though you may not realize it. What you are doing is *publishing* something, which alleges to be a factual list. Who is on it, who is not on it, and who uses it and how, matter a great deal. If the list is 100% complete and 100% accurate and 100% timely, there are no problems. Any deviation from that situation, regardless of how much and in what manner the deviation occurs, puts the publisher of alleged facts at risk. And relying on authoritative sources to push data to you, is a reverse onus that hundreds of years of case law quite likely present a formidable obstacle, if it becomes necessary to defend your choice. Here's a concrete analogy that may be suitable for demonstrating the issue. Imagine a magazine dedicated to Tires. It publishes an article on Tire Safety. It contains a list of Tires (manufacturer/model) safe to use at 180 km/h. Is the list accurate? Timely? Complete? If a reader bases a safety decision (buys tires, drives 180 km/h) that goes badly, then what? What about recalls? Also: Publishing a list may be even *riskier* than publishing a single, but erroneous, fact. E.g. what about manufacturers not listed? They have been implicitly or even explicitly defamed, even if you include a footnote to the effect that this list is not complete. If you are concerned that we will withhold changes or issue known-incorrect lists in order to conduct some sort of vendetta against a particular TLD, all I can say is why on earth would we do that? No malice is needed on your part, for publishing a list to cause problems, esp. for you and the publisher (Mozilla). I think you might not have considered that, yet. Conclusion: Regardless of the benign intent of the list, publishing it means needing to keep it timely, accurate, and complete, and that is why the notion of updates based on volunteered data from registries, updated only when software updates are performed, is a particularly bad idea. I happen to think that the idea of maintaining such a list is probably not a bad idea itself. It is the means by which the list is built, and distributed, that are of great concern. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Wed, Jun 11, 2008 at 12:26 PM, Gervase Markham [EMAIL PROTECTED] wrote: Incidentally - have you answered by question yet - or put it on the web site? What happens to your web browsers behavior if I try to surf a TLD not on the list? I've answered it once to you privately and once to the list. Third time: the same thing as now. We must be having email issues. Because I have neither received a private email from you that I can find. Will check my spam folder in case it ended up there. And I have not seen a response to my question on the list. Its been pretty busy here since you dropped this little bomb that has gotten us so excited. So please help me out here, I didn't get that answer. So what is the answer to the question ??? What happens to your web browsers behavior if I try to surf a TLD not on the list? Thanks in advance for your answer. Joe Baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, On Jun 11, 2008, at 4:26 AM, Gervase Markham wrote: It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. I guess it depends on what you mean by 'workable'. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. While I might agree that it is unlikely you'll get all the TLDs to agree on or do anything (they are a wildly varying bunch in pretty much every axis) I don't remember anyone suggesting you wait on the TLD operators to set up their own repositories. What I do remember folks saying is that hardcoding a list in other contexts has caused lots of trouble in the past and that it is probably a mistake for you to do it in your product. Some folks have even suggested alternatives (although I gather you do not consider them 'workable'). If I understand correctly, if there is no data (regardless of the solution), you get no change in behavior. As such, doing a probe for policy data when it is needed would seem to be workable. If there is no data available (for whatever reason), you get no change in behavior. If there is data, you get the most up to date available. Whether or not you start with a static list that is then over-ridden by the response from the probe is an implementation choice that can be argued. FWIW. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Gervase Markham: Say adserver.co.uk has contracts with mybank.co.uk, mygrocer.co.uk, mypetstore.co.uk to supply them with ads. adserver.co.uk can set the ad-tracking cookie for .co.uk and build up a cross-site profile of a particular user, perhaps augmented by information passed to them by one or more of the sites concerned. This is a privacy issue. I'd love to see an official statement from the Mozilla Foundation that cross-domain ad correlation is evil, and should be stopped by technology. Certainly this is not what you're trying to say here. I guess the real issue is that by setting a cookie for co.uk, it's possible to exploit session fixation vulnerabilities in web sites under co.uk. Unfortunately, the Public Suffix List web site is a bit unclear in this regard. It does not list a single protocol spec which requires this sort of data. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 11, 2008, at 3:16 PM, Florian Weimer wrote: I guess the real issue is that by setting a cookie for co.uk, it's possible to exploit session fixation vulnerabilities in web sites under co.uk. Unfortunately, the Public Suffix List web site is a bit unclear in this regard. It does not list a single protocol spec which requires this sort of data. It's kind of assumed that you would be aware of these issues, I guess. Lots of web sites use cookies to associate a session with a particular user. With cross-site cookie theft, a malicious web site can gain access to your session cookie even if it was protected by https encryption when you were talking to the legitimate site. Of course there are ways to mitigate this risk, but the only knob the mozilla guys have to turn is preventing the cookie from being leaked in the first place. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Ted Lemon: It's kind of assumed that you would be aware of these issues, I guess. But hardly anybody seems to be. Lots of web sites use cookies to associate a session with a particular user. With cross-site cookie theft, a malicious web site can gain access to your session cookie even if it was protected by https encryption when you were talking to the legitimate site. Yes, but that's why cookies are associated with the host name of the incoming request. The cookie set operation controls which domains can read the cookie. No special data is required for that. What's happening here is that a restriction is placed on the largest possible subtree for which you can set a cookie. Failure to do this does not grant read access to arbitrary cookies in itself. But as I wrote, it might expose session fixation problems. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Jun 11, 2008, at 3:30 PM, Florian Weimer wrote: Failure to do this does not grant read access to arbitrary cookies in itself. But as I wrote, it might expose session fixation problems. Right, the point is that the mozilla guys can't force web site implementors to do the right thing, but they still get dinged for a security flaw if the web site implementors do the wrong thing. The only knob they can turn is this one. So it makes a great deal of sense for them to try to turn it. Also, you discounted the privacy issue in your previous message, but the point is that in some countries privacy is actually a legal requirement, one which the Mozilla folks, I think rightly, feel some obligation to honor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Hi Gervase, At 02:15 11-06-2008, Gervase Markham wrote: They don't have to. Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? Does that mean that the new Firefox will never display domains that allow its users to be fooled or defrauded? :-) At 04:25 11-06-2008, Gervase Markham wrote: It's not true that we won't work on any other solution. This is what we have now, and there have been no alternative proposals which (to my mind) look like producing anything workable in the short term. If you push aside all the negative views, you won't see any alternative proposals. Half this list seems to think that getting all the TLDs to agree on or do anything is an enterprise doomed to failure, and the other half seem That's because there are some people on this list who have attempted that before. to think that we should be waiting for all the TLD operators to agree to set up their own repositories of the data. There is a contradiction there. Maybe those people are not looking for a short-term fix. By the way, the question of suffix lists has been discussed in other Internet areas before. It's not restricted to cookies only. The fact that nobody pointed you to a RFC suggests that there hasn't been an acceptable solution yet. Quoting RFC 4085: Products that rely on such embedded IP addresses initially may appear to be convenient to the product's designer and to its operator or user, but this dubious benefit comes at the expense of others in the Internet community. Replace IP addresses with publish suffix and you'll see why your proposal generated so much controversy on this mailing list. Regards, -sm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Wed, 11 Jun 2008, Gervase Markham wrote: Dean Anderson wrote: That's unfortunate; but I must say this upset was not communicated to me. Probably that's because you are using SORBS to filter your email. SORBS has an unusually high number of false positives, and for example, falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You can find more information about SORBS on http://www.iadl.org/ No-one can have control over and knowledge of everything their ISP does with relation to the services they provide. Actaully, I looked into the 'Our ISP blocked our mail without our knowledge' claim. [I'm always interested in the cases where this is true]. In fact, Mozilla's email is handled by mailservers on 63.245.208/20, which is a /20 assigned to Mozilla.org. It struck me as quite odd that quite strange that Mozilla.org has 4096 IP addresses, and that it got this assignment in 2006, under what should have been very strict usage and allocation rules...I wonder how Mozilla.org justifies 4k public IP addresses---Question for a different forum. Anyway, using SORBS isn't a decision you can blame on your ISP. Its Mozilla.org's mailserver, not an outsourced ISP mailserver. Mozilla.org has control over its email filtering, and it seems likely a Mozilla.org admin configured SORBS. It was not their ISP. This affects at least my view of your credibility. I confess I've only ever vaguely heard the name SORBS, and had no idea that my provider was using it. But I don't believe that using it makes me uncontactable. My phone number and address are on my personal web page. I can hardly imagine some TLD administrator saying I'm so irritated about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty email. Hang on, my email's been rejected. Oh well, I guess I'll just have to live with it. Well, somehow they managed to convey their upset'ness to ICANN, but not convey that to Mozilla. I don't know exactly why that was. But people often don't try very hard to overcome communication problems to tell someone that they are unreasonably off in the weeds. A SORBS bounce would tend to confirm the effort is pointless. That policy of ours should have no effect whatsoever on TLDs with a responsible attitude to homographs. Our registration requirements are not onerous. ??? This statement doesn't seem very credible. What authority do you have to decide what a 'responsible attitude to homegraphs' would be? What's your answer to that question? (Hint: the answer no-one is equivalent to the answer the registries, which has been shown not to work. See http://www.shmoo.com/idn/ .) I don't see that the answer is no-one, nor that the registries has been shown not to work, as you claim. However, if you think there is a problem and you have a solution that should be imposed on the TLDs, you should take the matter up with ICANN. Your unilateral exercise is certainly no solution. Mozilla.org doesn't represent the internet industry nor any government or governing organization. No, we represent our users, and we make all sorts of security decisions for them on a regular basis. Hmm. Worrisome, given the apparent lack of serious thought put into some of those security decisions, and the lack of credible, serious thought put into even anti-spam choices, and the blaming of things on your ISP. One of the reasons Firefox is popular is precisely because it doesn't wimp out of security decisions with user-irritating popup questions they have no information to answer. I also use firefox, but certainly not for those reasons. I use it because it came with Linux, and it displays HTML pretty reasonably. I didn't know it might have other dubious agendas hard-coded. But, as someone else has said, if people don't like the decisions we make, they can either become part of we and seek to change them, or they can change or build their copy, or can distribute an alternative browser. Actually, I said that. Perhaps others did, too. Why should TLD's think they need to register with Mozilla.org? They don't have to. Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? You have no justification to form that conclusion. The TLDs aren't defrauding anyone; The TLDs aren't aiding in the fraud of anyone. And your scheme isn't even shown to stop fraudulent websites. So Mozilla.org seems to have little to no justification whatsoever for its extremely unilateral actions. The people who register their domains with any certified TLD do have an automatic right to have Firefox display their websites. You have no right to assert they are fraudulent when they aren't and you have no evidence they are. I don't get a good feeling about Mozilla.org, anymore. The unrealistic, unilateral attitude reminds me of other kinds of similar extremism, that was also found to be unsubstantiated, and a
Re: [DNSOP] Public Suffix List
On Mon, Jun 09, 2008 at 04:53:01PM -0500, Ted Lemon [EMAIL PROTECTED] wrote a message of 16 lines which said: Why not just set up a list of TLDs in a mozilla.org subdomain, sign the subdomain with DNSSEC, put the DNSSEC public key into firefox, and have firefox consult the TLD list in the DNS, verified with DNSSEC, whenever information is needed? Your proposal solves *one* problem (the one well explained by Andrew Sullivan), the difficulty of having an up-to-date list in the installed browsers. It leaves open the other problems: * Difficulty of managing this list (and even worse if every browser vendor ask the TLD managers for a slightly different info) * Administrative boundaries at lower levels (if we delegate under .fr, it says nothing about x.example.fr and y.example.fr: are they in the same administrative domain?) * Mozilla's methods of arm-twisting ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Mon, Jun 09, 2008 at 04:51:02PM -0700, Paul Hoffman [EMAIL PROTECTED] wrote a message of 28 lines which said: you will notice that a few TLDs that allow IDNs have not registered with Mozilla for various reasons (*cough* *cough* .com, .ru, .many-countries-in-the-arab-speaking-world, ...). It would be interesting to know if it was a deliberate decision (because they did not appreciate an unilateral policy) or negligence. AFAIK, none of these TLD explained their decision publically. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: You're talking about essentially creating a registry of their registry policies and distributing it statically via your product. I would imagine they might be interested and might even have some useful input to provide. We're about to ask them for their input. Just to be clear, my understanding of the situation is that you are proposing to ask that every TLD who has a zone in which the public can register to notify you of that fact so that you can distribute and use a list of these registries within your product, relying on Mozilla's update/upgrade functionality to update and maintain this list. Explicit in this proposal is that the registries notify you every time they add a new 'public registry' or change the status of an existing 'public registry'. Failure to update a registry could have negative impact on customers of the TLD due to, for example, being unable to set cookies. Is this an accurate summary? Yes, basically. For best results we'd get the data directly from those in the know, but if they don't want to keep us informed, they don't have to. If you think this is unreasonable, what is the alternative position? - No, sorry, you can't do any of the things for which you might want this data - It's fine to want this data, but you should get it via this alternative method:... P.S. If you do send your message to the technical contacts for all the TLDs, expect quite a few bounces. OK - thanks. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: Jamie Lokier wrote: Gervase Markham wrote: Wouldn't it be more appropriate for MyBank to _itself_ say the history for these sites should be grouped? E.g. in an HTTP response header, or DNS record for mybank.co.uk? The total amount of effort required for this solution is mind-boggling. How is it more work for them to publish over DNS or HTTP, than to send you the information to publish, with the associated time lag etc? Your solution requires every site to set HTTP response headers, or every ISP to contact their customers to get the correct values for the DNS records. My solution involves communicating with a far smaller group. No, I don't think so. The information would be published in the ISP's TLD-alike domain, not the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming the information is each domain $WORD.co.uk is independent. The values are the same information that you are gathering. The ISP/NIC (Nominet UK for .co.uk) does not need to contact their customers for this: it's a .co.uk policy. You've asked for the same thing: for administrators of certain domains to provide you with information about independent or related users of those subdomains. But the two plans are talking about two different sets of admins, one vastly larger than the other. See above. -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Stephane Bortzmeyer wrote: * Difficulty of managing this list (and even worse if every browser vendor ask the TLD managers for a slightly different info) We are making our data available for everyone to use, so we are trying hard to make sure this doesn't happen. * Administrative boundaries at lower levels (if we delegate under .fr, it says nothing about x.example.fr and y.example.fr: are they in the same administrative domain?) This problem exists today, so there is no difference between Firefox 2 and 3 on this question. * Mozilla's methods of arm-twisting We aren't twisting anyone's arm. We are making a request for help. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: The information would be published in the ISP's TLD-alike domain, not the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming the information is each domain $WORD.co.uk is independent. The values are the same information that you are gathering. The ISP/NIC (Nominet UK for .co.uk) does not need to contact their customers for this: it's a .co.uk policy. OK. Then we are basically back to Yngve's suggestion. But this does require universal take-up for universal support - and that, as someone else has pointed out, makes it (in my opinion) doomed. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Kim Davies wrote: This thread sounds remarkably like deja vu. Indeed, the TLD community was rather upset a few years ago by Mozilla taking unilateral action to introduce a hard-coded white-list of acceptable IDN TLDs without prior consultation. That's unfortunate; but I must say this upset was not communicated to me. That policy of ours should have no effect whatsoever on TLDs with a responsible attitude to homographs. Our registration requirements are not onerous. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Paul Hoffman wrote: One possible method is to start Firefox 3.0 with an empty registry, and fetch a registry update from Mozilla each time a user does either a manual or automatic check for updates on Firefox. That's an interesting idea. We didn't make the data remotely-updatable on its own for Firefox 3, but we may be able to do so for the next release. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 . Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: Jamie Lokier wrote: The information would be published in the ISP's TLD-alike domain, not the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming the information is each domain $WORD.co.uk is independent. The values are the same information that you are gathering. The ISP/NIC (Nominet UK for .co.uk) does not need to contact their customers for this: it's a .co.uk policy. OK. Then we are basically back to Yngve's suggestion. But this does require universal take-up for universal support - and that, as someone else has pointed out, makes it (in my opinion) doomed. Or you gather data and hard-code it as a starting point, but simultaneously provide a mechanism for others to publish information about themselves which you use in real time, which overrides the hard-coded data if they use it. -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: - No, sorry, you can't do any of the things for which you might want this data - It's fine to want this data, but you should get it via this alternative method:... I'm inclined to suggest: Gather and hard-code your list into Firefox, and also provide a mechanism by which domain authorities can publish information which overrides your list for their domain. E.g. When evaluating online.myservice.free.fr, Firefox could look up DNS records for online.myservice.free.fr, myservice.free.fr, free.fr and .fr (in that order), and if there's a record use that. If not, use the hard-coded information you have gathered for that domain. In this case, you would expect, eventually, that free.fr may publish a record indicating that $NAME.free.fr are independent adminstratives entities, and that's the first record you'll fine. One day, someone creates dyndns.littleisp.free.fr, and lets people register themselves underneath that domain. (Such as littlecustomer.dyndns.littleisp.free.fr). Then, instead of contacting you and trying to get their information into your next Firefox update, they would simply publish a DNS record on dyndns.littleisp.free.fr, and the information would be live immediately. Not just for Firefox, but for any web client which adopts the same scheme. (By the way, although we're talking about administrative divides in the DNS tree, a little thought might be given to administrative divides in URL trees. There are a fair number of sites containing http://domain.com/user1/* and http://domain.com/user2/*, where those prefixes indicates separately administered URL spaces. Do similar cookie issues apply? Should a mechanism for publishing details of administrative divides include URL spaces for the same reasons?) -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On mån, 2008-06-09 at 17:28 +0100, Gervase Markham wrote: It would be an appropriate mechanism; when it does contain this information, let me know. It won't until someone specifies in how the data should be represented in DNS. And DNS is where it belongs, in the zone it relates to. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
From what I can tell: a) the proposed problem is that of cookies being used across differently administered web sites. b) the proposed solution involves mapping the boundary between privately and publicly administered DNS space. I don't see how (b) addresses (a). Web sites does not equal DNS. Private vs public DNS does not equal differently-administered websites. Furthermore keeping an accurate map of the DNS boundary is impossible. So to me it seems like the wrong tool for the job. Given that this model has been chosen, in the knowledge that it's based on an assumption that the problem cases in (a) are addressed by (b), how well has that assumption been tested? The boundary issues should be well known. Several have been raised already on this list. I'd be interested in seeing Mozilla's analysis of them. My feeling is there will be a lot of false positives and negatives near the border, since the solution is in a different space to the problem. Given the amount of work entailed in attempting to do (b), surely there's a responsibility to do this right? I fear such a crude tool will not only cause problems for users, webmasters and TLD managers, but also leave ample room for people to circumvent its intent, leaving us worse off than we are now - still with cookies broken, still with privacy issues and XS issues, but now a major browser vendor causing DNS administrative havoc, and forcing people to rewrite their websites as well. How to win friends and influence people. And the justification for this is that it will Allow some safe cross-site cookies? What happens when it doesn't do that? Do people even care enough about that to live with this solution? In a perfect world if this turns to custard, only Mozilla would suffer, but this isn't a perfect world, and actually I'm sure we'd all like Mozilla to live long and prosper. In the end what will be the deciding factors? I see users dumping FF3 when it doesn't work with the websites they know and trust. I see the reviews bemoaning compatibility issues. Mozilla needs to be careful when introducing something like this that can create many compatibility issues where the previous version didn't have them. In the end if some large jurisdictions refuse to play along, where does that leave Mozilla's users? Looking for another browser perhaps.. Unless Mozilla feels it has too many users, I'd urge caution in that area. As an absolute minimum a way to turn it off... even if it is buried deep in about:config (and you can't seriously expect us to believe that a required criterion for a setting being in there is that it can be understood by the majority of users). Regards Adrien Gervase Markham wrote: Jamie Lokier wrote: The information would be published in the ISP's TLD-alike domain, not the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming the information is each domain $WORD.co.uk is independent. The values are the same information that you are gathering. The ISP/NIC (Nominet UK for .co.uk) does not need to contact their customers for this: it's a .co.uk policy. OK. Then we are basically back to Yngve's suggestion. But this does require universal take-up for universal support - and that, as someone else has pointed out, makes it (in my opinion) doomed. Gerv -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Adrien de Croy wrote: Allow some safe cross-site cookies? What happens when it doesn't do that? Do people even care enough about that to live with this solution? I must admit, I don't see what's wrong with disabling cross-site cookies entirely. If two related domains want to transfer credentials, sessions etc., there are other mechanisms to do it. In the end what will be the deciding factors? I see users dumping FF3 when it doesn't work with the websites they know and trust. I see the reviews bemoaning compatibility issues. Mozilla needs to be careful when introducing something like this that can create many compatibility issues where the previous version didn't have them. In the end if some large jurisdictions refuse to play along, where does that leave Mozilla's users? Looking for another browser perhaps.. Unless Mozilla feels it has too many users, I'd urge caution in that area. Perhaps the list should be used to implement a warning, easily overridden per site, like the other cookie dialogs which Mozilla pops up, rather than a hard block. As a user I might prefer that. I already like being able to say no thanks to cookies on sites where I don't see any need. -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Gervase Markham: If www.flirble.co.zz and www.widget.co.zz wished to conspire to track users across the two sites, they would simply both say that they are happy to accept co.zz cookies. Right now, they're sharing that bit of information through one of Google's web bug services. Cross-domain cookies would at least provide some level of transparency. So this argument is a bit questionable. I am not particularly interested in a long discussion about whether we need this data. Please be assured that we need it. I am, on the other hand, open to suggestions about better ways to obtain it. You need some sort of out-of-band service. The information you are looking for is not encoded in DNS. Whether it's necessary to provide automatic, non-code updates of the out-of-band data is a difficult question. However, this looks somewhat like the IP bogon prefixes list, where hard-coding that ever-changing part into router configurations turned out to be a big mistake. For the DNS folks: The web security model requires that www.example.$TLD and login.example.$TLD (where $TLD may contain multiple labels) can share cookies (and probably HTTP requests, but I don't do that AJAX stuff). This must work by default, without explicit marking by the web site operator, or tons of deployed applications will break. At the same time, it should not be possible to set cross-domain cookies (that is, a cookie for login.example.$TLD by serving a HTTP request for login.otherexample.$TLD). Well-written web applications should be immune to that, but lots of them apparently aren't. This is the status quo. Javascript is constantly enhanced with database and stuff like that. As a result, you aren't just protecting mere cookies, but much more. Obviously, this approach is not sound. But even with those later changes, some means to divine administrative boundaries from DNS names are required for plain cookie management. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Brian Dickson: If you want grouping, there is a simple-to-code, reliable, and authoritative way to do so. Zone cuts (in DNS). This is an bad idea because introducing a new zone at an existing name should really, really be transparent to the rest of the world. (Thanks to configuration options like (root-)delegation-only, this is already not true to some extent, but there's no reason to repeat past mistakes.) What's worse, bringing technical and administrative delegation into agreement requires significant changes, which are unlikely to happen. You need to take into account that this data is not just needed to make new services secure on the surface, but also to deal with fairly old protocol mishaps. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Florian Weimer wrote: * Gervase Markham: If www.flirble.co.zz and www.widget.co.zz wished to conspire to track users across the two sites, they would simply both say that they are happy to accept co.zz cookies. Right now, they're sharing that bit of information through one of Google's web bug services. Cross-domain cookies would at least provide some level of transparency. So this argument is a bit questionable. The problem is specific to HTTP cookies, not DNS or TLDs. Mozilla (and anyone else who shares concern) should try to help fix the cookie SPEC (RFC 2107), not cook up ways to work-around it. -- Some days it's just not worth chewing through the restraints... Mark D. Foster, CISSP [EMAIL PROTECTED] http://mark.foster.cc/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Jamie Lokier: E.g. When evaluating online.myservice.free.fr, Firefox could look up DNS records for online.myservice.free.fr, myservice.free.fr, free.fr and .fr (in that order), and if there's a record use that. If not, use the hard-coded information you have gathered for that domain. Isn't this the wrong direction, that is, should you start from the TLD? (But don't forget to put that record into a separate zone. 8-P) (By the way, although we're talking about administrative divides in the DNS tree, a little thought might be given to administrative divides in URL trees. There are a fair number of sites containing http://domain.com/user1/* and http://domain.com/user2/*, where those prefixes indicates separately administered URL spaces. Do similar cookie issues apply? Yes. I think Ebay suffers from these issues. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
* Stephane Bortzmeyer: On Mon, Jun 09, 2008 at 10:29:27AM -0400, Andrew Sulli5Avan [EMAIL PROTECTED] wrote a message of 52 lines which said: Is there any way to turn this off in Firefox 3? Switch to a free software browser without this very bad policy? http://www.konqueror.org/ Have a look at this file: /usr/share/apps/khtml/domain_info That's my last posting for today. Sorry about the mail flood, I got carried away a bit. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On tis, 2008-06-10 at 11:13 +0100, Gervase Markham wrote: OK. Then we are basically back to Yngve's suggestion. But this does require universal take-up for universal support - and that, as someone else has pointed out, makes it (in my opinion) doomed. Not really. By proper design you can easily make cross-site cookies be verifiable. Set out the goal that a site must indicate that cross-site cookies is allowed for it to be accepted, and then work from there. There is many paths how to get there, and the more delegated you make it close to the owners and operators of the sites the better. The big question is what that design should look like, but it's certainly not a central repository with copies hardcoded into software. It's also not likely DNS as DNS is hop-by-hop in the HTTP world and cookie management is end-to-end.. (the user agent might not even have DNS access) Securing cookies by blacklisting is not the right approach for many reasons, and should only be seen as a temporary patch along the path to secure cookie management and at best input for a interim default policy in the next step on the road to secure cross-site cookie management. Blacklisting is not a very bad idea, but neither long term viable or flexible enough to work out well. But on the positive site it's a small step forward from what we have today and very unlikely to cause problems. But on the bad side it hides the problem making it more likely to bite unsuspecting owners of domains in public registries which for some reason isn't in that list.. Delegated whitelisting is the only approach that has a reasonable chance of working out well in the long run imho. There is so many public registration points today, and it will significantly increase over time. Preferably done at the HTTP level or at least using HTTP as transport, and not relying on number of components stripped from the requested host name and similar silly rules. It should be possible to set a cookie for www.example.com and www.example.net in a single transaction. Another alternative would be to finally rework the cookie system proper addressing this and the many other shortcomings of the current cookie system, Reworking the cookie system would be nice, but I don't see this likely to happen until HTTP/2.0... Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On tis, 2008-06-10 at 13:45 +0200, Henrik Nordstrom wrote: On mån, 2008-06-09 at 17:28 +0100, Gervase Markham wrote: It would be an appropriate mechanism; when it does contain this information, let me know. It won't until someone specifies in how the data should be represented in DNS. And DNS is where it belongs, in the zone it relates to. Some more brain cells fired in a later response and DNS is after all not the proper location for this to work out in HTTP. See separate response. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On tis, 2008-06-10 at 21:05 +0200, Florian Weimer wrote: stuff). This must work by default, without explicit marking by the web site operator, or tons of deployed applications will break. I seriously question this will break part. Sure, they will get annoyed, but in nearly all possible solutions layering ontop of the existing cookie system there will be easy ways for the owners of such sites to make them behave well, and a transition period giving them inciative and reasonable warning period to do so. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On tis, 2008-06-10 at 21:25 +0200, Florian Weimer wrote: Isn't this the wrong direction, that is, should you start from the TLD? Not if done for the receiving site, but yes if done based on the site setting the cookie.. Regards Henrik signature.asc Description: This is a digitally signed message part ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Tue, Jun 10, 2008 at 09:39:01PM +0200, Florian Weimer [EMAIL PROTECTED] wrote a message of 18 lines which said: /usr/share/apps/khtml/domain_info On my system (an up-to-date Ubuntu), it contains: twoLevelTLD=name,ai,au,bd,bh,ck,eg,et,fk,il,in,kh,kr,mk,mt,na,np,nz,pg,pk,qa,sa,sb,sg,sv,ua,ug,uk,uy,vn,za,zw I assume it is a list of TLD which register at the third level. If so, it is questionable (.af, .dz, .fr register at the second and the third level and I do not know how Konqueror handles it). So, I got your point: other browsers have the same similar (and wrong) policy. Bad news. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
-Original Message- From: bert hubert [mailto:[EMAIL PROTECTED] 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 ? Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E [EMAIL PROTECTED] W http://www.sidn.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
(Responding only on the DNS list to avoid cross posting.) At 14:11 +0200 6/9/08, bert hubert wrote: On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote: (...) I'm very afraid that Mozilla is trying to hijack the authority model here. You can't hijack something that does not exist though, which is what I think is the problem here. Yes you can hijack something that doesn't exist (for varying values of existence). This is the same situation that the RIRs faced with the bogon lists for IP address prefixes. (The problem peaked as recently as 2005 - i.e., it was a recent one.) ISPs would filter out all traffic to the unallocated slash-8's (as listed by IANA as inactive). When an RIR was allocated a slash-8, even an announcement on mailing lists wasn't enough to get all filters changed. Now the RIR's put in test addresses for traceroutes and pings to allow checks for bad filters. If the browsers do implement a check based on TLD name, I bet they are also gullible enough to implement RFC 3514. Keep in mind that there is more than just the ICANN root zone DNS in the world. Perhaps the thought is that it is the only legitimate root zone on the global public Internet but there are other global inter-networks. These networks also employ DNS albeit operating under a private administration. A browser that is hard-wired for the global public Internet would be a problem on these private networks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
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
Re: [DNSOP] Public Suffix List
On 9 jun 2008, at 15.41, Gervase Markham wrote: Patrik Fältström wrote: The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think. This isn't so. For TLDs not in the list, the usual rules (about e.g. cookie setting) would be applied. In other words, the situation is no different to what it is now. This information is additive. What about new structures in a TLD that is in the list? I.e. I do understand what you want to do, but am nervous still about the result if the list is not updated. Yes, you say your software is updated often, and sure, you might be the best in the class. I just felt it was sort of my job to point out the risks, specifically as the risks are written down. What you at the end of the day do is of course up to you. ;-) Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström [EMAIL PROTECTED] wrote: The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think. That is why my subtld-structure draft is suggesting that TLD profiles be downloaded at regular intervals (and at need) from a repository, in order to make it possible to add new TLDs or new registry-like domains under a TLD, and to prevent problems with old software. My drafts also suggest a rule-of-thumb fallback in case a TLD is unknown. -- Sincerely, Yngve N. Pettersen Senior Developer Email: [EMAIL PROTECTED] Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax:+47 24 16 40 01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote: On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström [EMAIL PROTECTED] wrote: The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think. That is why my subtld-structure draft is suggesting that TLD profiles be downloaded at regular intervals (and at need) from a repository, in order to make it possible to add new TLDs or new registry-like domains under a TLD, and to prevent problems with old software. My drafts also suggest a rule-of-thumb fallback in case a TLD is unknown. This thread is going to go around in circles for quite a while. There's a history of the IETF wanting to define something without fixed boundaries. DNS names is one, IPv6 addresses is another. But when it comes to operations, having fixed boundaries makes mass production much easier. E.g., in IPv6, IETFer's (as we know, the IETF doesn't have any official statement source and no members, so I refer to those in the debate that brandish IETF credentials) would say that the days of classful addressing are behind us, so IPv6 addresses ought to be treated as nothing but a string of 128 bits. But RIR policy writers wanted to know whether to recommend /48's, /54's, /32's, etc. for certain types of uses. (Uses not users.) Shifting back to DNS, there's not going to be a scientific differentiation between one zone and another. During the DNSSEC development days we wanted to declare some zones as widely delegated (such as .com) from other zones - to alleviate the issues we see with NSEC, NSEC3, etc. that are apparent still now. There's nothing in DNS to differentiate, at a protocol level, one zone from another, but at the operational end of the stick, there are many differentiators (like whether the administration interface is on paper or via EPP). I doubt that you'll find any repository that can be used to register registry-like zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's thumbs on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's a market place with operators, wholesalers, resellers, etc. I think the answers to building a domain's reputation lie more in what happens at an ICANN meeting than an IETF meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Wes Hardaker wrote: I think a better policy would be to fix the HTTP protocol so that it could specify an incoming cookie policy. Rather than having every site under the sun be able to set cookies and block that by some random list of hard coded within list, allow each site to specify where they accept cookies from. That doesn't solve the privacy problem. If www.flirble.co.zz and www.widget.co.zz wished to conspire to track users across the two sites, they would simply both say that they are happy to accept co.zz cookies. I am not particularly interested in a long discussion about whether we need this data. Please be assured that we need it. I am, on the other hand, open to suggestions about better ways to obtain it. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Patrik Fältström wrote: What about new structures in a TLD that is in the list? If the structure is additive, then again there is no problem. If it is reductive, then there are potential problems depending on how the customers of the newly-available domains set things up. Let us say, for example, that the .zz domain has five sub-levels, which are the only places you can register: com.zz org.zz net.zz ltd.zz plc.zz So this is what the list will say. Now, say the .zz domain changes their policies to permit direct registration under the root. If someone purchases foo.zz, they will not be able to set a cookie for foo.zz until the list is updated. They will, however, be able to set one for www.foo.zz. So what is inhibited is the sharing of cookies across different sites in the same domain, not the setting of cookies entirely. I agree that this is not ideal. But I believe what we are doing now is the least worst option, and that good publicity for the scheme among the TLD owners will mean that if they are considering such a move, they will let us know. I hope that publicsuffix.org (or somewhere more official) will become the single source for this data. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker [EMAIL PROTECTED] wrote: EG, if I had www.example.com and I received cookies in a request from example.com, images.example.com and hacker.com I could determine Not sure if you mean that www.example.com is sending cookies for example.com, images.example.com and hacker.com, of which only the first is legal, or that www.example.com includes resource that sets cookies for those destinations, which can be controlled by third-party cookie filters. based on the source which ones I wanted to accept. The current issue with cookie usage is that sites don't have the ability to not accept data from external sources. Fix that problem instead and you'll have a much better and more scalable solution. It'll require work on both the server side and the browser side but in the end is a better solution. RFC 2965 requires the client to send the domain along with the cookie under some conditions. My suggested update of RFC 2965 URL: http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-02.txt , which changes the domain semantics, also suggest sending the domain for _all_ cookies, also those set using old versions of the specification, and the name of the host setting the cookie (if known) for cookies set using the older versions. For cookies, the primary problem here is limiting what the client can set, so that malicious.co.uk cannot set a cookie that will be seen by mybank.co.uk, or that can be used to track users across several domains (without advertising that they do share the information). Requesting permission from the server (or individual resources) to send cookies will require an extra turnaround, thus reducing performance. -- Sincerely, Yngve N. Pettersen Senior Developer Email: [EMAIL PROTECTED] Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax:+47 24 16 40 01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Andrew Sullivan wrote: Is there any way to turn this off in Firefox 3? Not that I know of. RFC 3696 explains, I think, most of the reasoning that I would offer for why I think this is a bad idea. I urge you and others who are planning to ship this kind of feature to go (re)read that RFC. Why do you think that the negative consequences explained in that RFC would apply in this case? Please think carefully about the consequences of possible failure scenarios. I know that you have a security problem, which is that cookies are widely used for some purposes in such a way that they can be subverted. That's a problem with the cookies specification, which was always broken. This isn't just about cookies. For example, we would like to group together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in history. Grouping together all sites in .co.uk does not provide for an optimum user experience. If you're not going to fix the cookies specification (which is what I think you ought to do, but I understand why people are reluctant to take that on), then there should at least be some way to publish data about the relationship you want to permit. One way to do this would be to figure out a way to publish lists of domains for which a given domain publishes cookies, and from which a given domain accepts cookies. As I noted in an earlier message, this may solve security problems but does not solve privacy ones. I still run into problems with email addresses in .info domains not being accepted, because the top level domain label is too long. Which is why the list is soft-fail - e.g in the cookie case, if a new TLD is added which is not on the list, we simply fall back on the current behaviour. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote: RFC 3696 explains, I think, most of the reasoning that I would offer for why I think this is a bad idea. I urge you and others who are planning to ship this kind of feature to go (re)read that RFC. Why do you think that the negative consequences explained in that RFC would apply in this case? Please think carefully about the consequences of possible failure scenarios. Because what you are proposing to do adds special meaning to certain labels (and their relative position) and not to others, in exactly the way that previously people had special interpretations of certain labels and their positions in the set of labels. What you're really trying to do here is extract meaning from the domain name, but you can't do that reliably. Previous efforts in that direction have failed in unexpected ways; and given that you seem to have multiple ways you want to use this feature, I don't see any reason to believe you won't have surprising failures too. The plan is both too narrow and too wide. First, it will almost certainly fail to capture 100% of the cases you currently don't want to succeed. Second, it will (as we've been arguing in this thread) not work for new TLDs and other cases. Your counterargument is that the behaviour will then fall back to the current arrangement. This means that different domains behave in different ways, and the user can't rely on any behaviour consistently. This isn't just about cookies. For example, we would like to group together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in history. Grouping together all sites in .co.uk does not provide for an optimum user experience. It seems to me that what you want is metadata about certain domains. Therefore, what you need is a mechanism for publishing metadata, not a magical list of domains about which you'll have hard-coded information. I agree with Ed Lewis's remarks that operators often want such lists. I understand the value of them. I am arguing that coming up with such a list and hard-coding it anywhere is a very bad idea, because users will not get predictable behaviour, particularly in new TLDs and other new areas of the DNS tree. That unpredictability of behaviour means that new services have yet more barriers to surmount before success. I think that's a bad thing. As I noted in an earlier message, this may solve security problems but does not solve privacy ones. That seems to be yet more reason to try to fix the cookies specification, rather than trying to impute metadata to the DNS labels. Obviously, it's your code, and you can do what you want with it. But I think this is a very bad idea, and I think it's a shame that it should be adopted anywhere. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, On Jun 9, 2008, at 4:48 AM, Gervase Markham wrote: Fortunately, Firefox has an extremely good and fast update and uptake rate. This is partly because we don't give users a choice about taking non-major-version updates. And how does this update/update rate take into account folks who use your product behind firewalls and/or who are constrained by policy to not update/upgrade? Or the folks that disable the version probe? Broken crap on the Internet has a half-life measured in decades. We've learned time after time that static lists of dynamic data compiled into globally distributed programs are simply a bad idea and that however, my view is that getting comprehensive buy-in would take quite a lot more time and effort than this method. is the common excuse that results in lots of broken crap on the Internet. It is sad to see the same mistake repeated again and again. How can non-TLD's get into this list!? Just by asking; I already got an email from CentralNIC. If there is no vetting, doesn't this defeat the purpose? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Andrew Sullivan wrote: Because what you are proposing to do adds special meaning to certain labels (and their relative position) and not to others, in exactly the way that previously people had special interpretations of certain labels and their positions in the set of labels. Right. But they did things like throw error messages saying That's an invalid domain name because it has too many characters in the extension. Please enter a valid one. We aren't planning anything like that. What you're really trying to do here is extract meaning from the domain name, but you can't do that reliably. Previous efforts in that direction have failed in unexpected ways; and given that you seem to have multiple ways you want to use this feature, I don't see any reason to believe you won't have surprising failures too. I think your statements of doom need to be more specific. The plan is both too narrow and too wide. First, it will almost certainly fail to capture 100% of the cases you currently don't want to succeed. That's true. It's an improvement to privacy and UI, not a magic bullet. Second, it will (as we've been arguing in this thread) not work for new TLDs and other cases. It will work perfectly for any new TLD which allows registration directly below the root. Of the seven new gTLDs introduced in 2001/2, this is true (as far as I can see) of .biz, .info, .name and .coop. So those four would have worked fine if this system had been in place and there had been no update. .museum and .name have sub-structure, but we haven't found a definitive list. If .pro were not present in the list, then people within the professional subdomains such as bar.pro could conspire to share cookies. The end-user effect of this is a minor loss of privacy, but none of function. Your counterargument is that the behaviour will then fall back to the current arrangement. This means that different domains behave in different ways, and the user can't rely on any behaviour consistently. But if consistent behaviour was the goal, then we _would_ allow privacy-busting cookies for .co.uk and .com.au, because those domains are just the same as foo.com, and we want consistency. Who is the user in your statement? This isn't just about cookies. For example, we would like to group together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in history. Grouping together all sites in .co.uk does not provide for an optimum user experience. It seems to me that what you want is metadata about certain domains. Therefore, what you need is a mechanism for publishing metadata, not a magical list of domains about which you'll have hard-coded information. As I have mentioned earlier in the thread, Yngve is proposing a scheme were every TLD operator publishes this information using a web service, and clients can look it up (and cache it). I personally think the chances of that happening are very slim. But if I am proved wrong, we can happily switch over to using it. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: however, my view is that getting comprehensive buy-in would take quite a lot more time and effort than this method. is the common excuse that results in lots of broken crap on the Internet. It is sad to see the same mistake repeated again and again. Prove me wrong, then. You can send a message to the Technical Contacts of all 284 domains (I can supply you with a list) saying Please set up a resilient, highly-available web service to provide current data on your registration structure. See what sort of reaction you get. How can non-TLD's get into this list!? Just by asking; I already got an email from CentralNIC. If there is no vetting, doesn't this defeat the purpose? Who says there's no vetting? How does adding e.g. CentralNIC defeat the purpose? In some ways, it is the purpose; CentralNIC customers will no longer be able to conspire to damage users privacy, and if users accidentally mis-set cookies, other CentralNIC customers can't steal them. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
David Conrad wrote: I suspect I might have a better list than you (:-) hint: I work at ICANN). Well, OK :-) My reading of Yngve's draft (in particular, section 5.1) led me to believe that all TLDs would not need to run such a service, rather that such a service be available in a well known place (I think the right approach would be for IANA to maintain pointers to well known places, but that's an implementation detail). I'm happy to admit that Yngve's solution, if it ever got up and running, would be a good one. (Although it's worth noting that such a service would need to deal with a non-negligible amount of traffic.) But it doesn't exist. I'm curious: have you consulted with the various TLD-related organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, etc.) on how to solve this problem? No. What do you think they'd say that hasn't been said in this thread already? We've had this basic problem in the domain of cookies for years. I don't expect another solution to pop out of the woodwork now. But I'm open to being surprised :-) Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: This isn't just about cookies. For example, we would like to group together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in history. Grouping together all sites in .co.uk does not provide for an optimum user experience. Wouldn't it be more appropriate for MyBank to _itself_ say the history for these sites should be grouped? E.g. in an HTTP response header, or DNS record for mybank.co.uk? Also, wouldn't DNS generally be the appropriate mechanism to say what grouping relationships there are under $DOMAIN? After all, the administrative control for the grouping info which you are maintaining for *.$DOMAIN, and DNS for *.$DOMAIN, are the same. -- Jamie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: Wouldn't it be more appropriate for MyBank to _itself_ say the history for these sites should be grouped? E.g. in an HTTP response header, or DNS record for mybank.co.uk? The total amount of effort required for this solution is mind-boggling. How is it more work for them to publish over DNS or HTTP, than to send you the information to publish, with the associated time lag etc? You've asked for the same thing: for administrators of certain domains to provide you with information about independent or related users of those subdomains. The only difference that I see, is you're able to include commonly known information about TLDs like *.com and *.co.uk. I agree with that: it's good to collect and publish the info. For the more obscure ISP-owned domains with independent user sub-domains, I don't see a difference in work _for them_ between you putting out a call and collecting the info, and keeping it update as new ISPs come on line, and the ISPs having a mechanism to publish it themselves. Except that the latter will be more accurate, and less work for you. -- Jamie Also, wouldn't DNS generally be the appropriate mechanism to say what grouping relationships there are under $DOMAIN? After all, the administrative control for the grouping info which you are maintaining for *.$DOMAIN, and DNS for *.$DOMAIN, are the same. It would be an appropriate mechanism; when it does contain this information, let me know. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Jamie Lokier wrote: Gervase Markham wrote: Wouldn't it be more appropriate for MyBank to _itself_ say the history for these sites should be grouped? E.g. in an HTTP response header, or DNS record for mybank.co.uk? The total amount of effort required for this solution is mind-boggling. How is it more work for them to publish over DNS or HTTP, than to send you the information to publish, with the associated time lag etc? Your solution requires every site to set HTTP response headers, or every ISP to contact their customers to get the correct values for the DNS records. My solution involves communicating with a far smaller group. You've asked for the same thing: for administrators of certain domains to provide you with information about independent or related users of those subdomains. But the two plans are talking about two different sets of admins, one vastly larger than the other. Gerv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase Markham wrote: We've had this basic problem in the domain of cookies for years. I don't expect another solution to pop out of the woodwork now. But I'm open to being surprised :-) Surprise! If you want grouping, there is a simple-to-code, reliable, and authoritative way to do so. Zone cuts (in DNS). (Note well - a zone is not semantically identical to a domain, although they can at times seem that way. In particular, if a child domain is served by the same server(s) as the parent, there will not be a zone cut. This, I believe, will generally do a good job of permitting grouping automagically.) Where there is a delegation of authority, via a zone cut, that is *exactly* where you want to group. And in the absence of a zone cut, you do not want separation by grouping. That (among other things) is what distinguishes foo.co.uk from myprivatesubdomain.foo.com. Perhaps examining other aspects of DNS responses may further inform the device needing to determine grouping. Things like presence/absence of glue (at particular places, e.g. root/TLD), commonality of NS instances between parent/child, etc. Whether this gets done by the end-user's client, or by some more-centralized box, is an implementation issue (but one that should be given lots of thought!!). But, it is better to trust information already published, which is required for proper operation of DNS, than to look for additional information that may become stale or inconsistent. Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase,
first I'd like to thank Yngve for providing the pointer and you for following
his advice.
I am not particularly interested in a long discussion about whether we
need this data. Please be assured that we need it. I am, on the other
hand, open to suggestions about better ways to obtain it.
Without discussing the perceived need it's hard to tell what good or
better solution might exist. From what I see and also from what I remember
from earlier discussions on this topic, you are trying to exploit a
property that the DNS simply doesn't have: You are trying to deduce
administrative grouping from proximity or hierarchy in the name space.
In spite of sloppy language that lets a domain have a policy or lets
a domain publish a website and so on, this is not what the DNS is about.
The DNS naming hierarchy does neither follow nor imply administrative
hierarchy. Therefore, as others already suggested, the discussion of
the need or the way cookies' scopes are defined is more needed than
details of a data collection scheme that appears to be in conflict with
very basic properties of the protocol.
-Peter {no hats}
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, The Dan Jay (and later) cookie policy drafts had a dsig in the payload so that the data collection policy (DCP) asserted in a cookie could be verified. The xml dsig draft wasn't ready, so we took off that part of the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San Jose a _large_ vendor agreed to implement what had been protoyped in Mozilla, replacing a no-3rd-party-cookies policy (there's reasonable policy claims on both sides of that) with parse-the-policy-user-decide policy (again, there's reasonable ...). It's not unreasonable to revisit how we know an assertion about a DCP is true, or provably false, as xml dsig is now mature. Turning to the list it self, I'm working on proposals (to ICANN) for new generic TLDs with string lengths greater than four bytes, and the latest estimate (by ICANN staff) is that they anticipate between 300 and 600 applications in 2009, zero or more of which may be operationalized in 2010. Additionally, a subset of the existing iso3166 code-point associated registries may elect to apply to add non-ASCII (well, technically, ACE junk) labels to the root. My point here is that two of the safe assumptions (byte count mumble ( sizeof(rootzone) compositionof(rootzone) ) are quasi-static) has a two-year or less shelf-life remaining. It isn't unreasonable to expect registry operators under contract (to ICANN) to publish SLD data directly, so you (and others) don't have to wikipedia (not that wikipedia isn't generally a better source of data), and you'd probably want that in machine readable form, with an update mechanism, and it might be useful if that request got incorporated into the process I mentioned above before it goes live. The PROVREG WG added a DCP into EPP, however, the intended scope was simply to announce the DCP of registry operators to registrars, who may then communicate the registry's DCP, and their own, towards the eventual registrant. We didn't provide a mechanism for registrants to announce the DCPs that they would be implementing from the resources they obtained by registering domains, or a mechanism for registries to announce DCPs scoped to a particular namespace. FYI, the elephant in the room for P3P is we didn't provide a means to assert linkage to data collected by other means, so data collectors don't have a means to announce if they do, or don't, link cookie data with credit-report data obtained by other means. We did, over the objections of one of the major deterministic personal profile vendors, now owned by a _large_ search engine operator, make linked data disclosure manditory through the include/exclude statements. Eric Gervase Markham wrote: Dear HTTP and DNS Operations WGs, The following email message will shortly be sent to the technical contact for all TLDs. Yngve Pettersen at Opera suggested that I also let you both know about it. The technology in question, including a version of the list, is about to ship in Firefox 3, but we'd like to verify and improve the quality of the underlying data. Please let me know if you see any way I can improve the email, the explanatory website, or the submission process. Gerv snip Dear Technical Contact, The Mozilla Project (http://www.mozilla.org/), responsible for the Firefox web browser, requests your help. We are maintaining a list of all Public Suffixes. A Public Suffix is a domain label under which internet users can directly register domains. Examples of Public Suffixes are .net, .org.uk and .pvt.k12.ca.us. In other words, the list is an encoding of the structure of each top-level domain, so a TLD may contain many Public Suffixes. This information is used by web browsers for several purposes - for example, to make sure they have secure cookie-setting policies. For more details, see http://publicsuffix.org/learn/. We would like your help to make sure, now and in the future, that the entries for your TLD(s) are correct. It is in your interest as a registry to make sure that this is so. Any errors may either cause your customers (domain owners in your TLD) to not be able to set cookies when they should, or cause cookie information to be leaked between two domains without a trust relationship. Neither of these things is desirable. Therefore, we are writing to ask your technical team to view the current list and, if it is incorrect, to submit updated data. A description of the format of the list, and details for sending updates is at: http://publicsuffix.org/submit/ We also ask you to send updated information whenever you change your registration policies in a way which affects the list. Thanking you in advance, Gervase Markham ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, I'm going to piggy-back this on something Edward Lewis wrote: ... I doubt that you'll find any repository that can be used to register registry-like zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's thumbs on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's a market place with operators, wholesalers, resellers, etc. I think the answers to building a domain's reputation lie more in what happens at an ICANN meeting than an IETF meeting. The model we had was that with a dsig in the payload, along with a DCP, the US FTC could pursue bad actors in the US, and these would be forced off-shore. Iterate until bad actors are restricted to well-known jurisdictions and policy set-cookie operations accordingly. Now I was profoundly dumb in several dimensions -- I didn't anticipate that the FTC would be indifferent to consumer fraud, I didn't anticipate that off-shore (meaning outside of Reston and its environs) would grow so dramatically, I didn't anticipate that the new entity would become part of the problem, creating a privacy hostile and consumer fraud indifferent regime in one part of the namespace, and failing to provide a mechanism for policy coordination across the entire namespace, and I didn't anticipate that we'd be wiped out in 2000, or that privacy would be wiped out as a policy area in 2001. That said, it is my experience that leads me to differ with Ed. The IE 5.5 beta blocked all 3rd-party cookies, and Mozilla's market share then was much smaller than it is today, yet our prototype of the policy parse policy model (in your code) was sufficient to cause that vendor to change their policy for IE 5.5, and hence for the entire market. I'm not unconcerned by the problems of state consistency (list update), or bit-delivery with that state embedded in each bit-set, or the specifics of discovery across 300+ mostly indifferent actors, or the (imho) larger problem of associating policy to namespace delegation or heuristics, but in my experience, the sink for all the set-cookie requests can independently, and usefully, determine the value of cookies and namespaces. We didn't use the IETF last time, other than to float drafts, in part because the HTTP-WG was closed, and ICANN didn't exist. Yet we got cookies into the only available model at the time, pretty much to solve the same problem you're trying to solve, modulo all the dumbness I mentioned above. Eric ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gervase, On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote: I'm curious: have you consulted with the various TLD-related organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD, etc.) on how to solve this problem? No. What do you think they'd say that hasn't been said in this thread already? You're talking about essentially creating a registry of their registry policies and distributing it statically via your product. I would imagine they might be interested and might even have some useful input to provide. Some might even think it rude (even Microsoftian :-)) not to ask. But perhaps I've been at layer 9 too long. Just to be clear, my understanding of the situation is that you are proposing to ask that every TLD who has a zone in which the public can register to notify you of that fact so that you can distribute and use a list of these registries within your product, relying on Mozilla's update/upgrade functionality to update and maintain this list. Explicit in this proposal is that the registries notify you every time they add a new 'public registry' or change the status of an existing 'public registry'. Failure to update a registry could have negative impact on customers of the TLD due to, for example, being unable to set cookies. Is this an accurate summary? Regards, -drc P.S. If you do send your message to the technical contacts for all the TLDs, expect quite a few bounces. It seems keeping whois data up to date is a challenge for many TLD admins. Having a bit of experience dealing with the various TLD administrators, this might be seen as cautionary towards what you're proposing to do. P.P.S. Before anyone asks, IANA policies disallow IANA from initiating a change and require all changes to be confirmed by the TLD admins -- IANA could harass people to update their info, but the TLD AC and TC must take action for a change to occur. This turns out to be quite a stumbling block. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Stephane Bortzmeyer (bortzmeyer) writes: On Mon, Jun 09, 2008 at 10:29:27AM -0400, Andrew Sullivan [EMAIL PROTECTED] wrote a message of 52 lines which said: Is there any way to turn this off in Firefox 3? Switch to a free software browser without this very bad policy? http://www.konqueror.org/ Less radical... about:config in firefox search for IDN disable network.IDN.whitelist for all listed TLDs. Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Mon, Jun 09, 2008 at 04:53:42PM +0100, Gervase Markham wrote: What you're really trying to do here is extract meaning from the domain name, but you can't do that reliably. Previous efforts in that direction have failed in unexpected ways; and given that you seem to have multiple ways you want to use this feature, I don't see any reason to believe you won't have surprising failures too. I think your statements of doom need to be more specific. I think you may be misplacing the burden of proof there. We have previous cases where apparently innocent inference of this sort of metadata about domains turned out to be harmful. I'm arguing, by way of analogy, that it is not unreasonable to suppose your approach may cause harm too. Your response appears to be that you won't cause that kind of harm. I'm sure that's true. But my argument is that, because you are relying on meanings that simply aren't in the DNS at all, your feature is automatically fragile. It will behave in ways that are surprising, because the behaviour of cookies (and, for that matter, of grouping of history stuff) will be based on hard-coded bits inaccessible to any user unwilling to read the source code. Also, new operators of various domains that may want to behave differently than your current expectation will be disadvantaged by what you're doing. Without getting every current user in the world to upgrade their client, they will continue to suffer that disadvantage to some extent. That seems like a kind of harm to me, but I appreciate that we may have different meanings of that word. Best regards, A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
I'm a little puzzled by this discussion. Why not just set up a list of TLDs in a mozilla.org subdomain, sign the subdomain with DNSSEC, put the DNSSEC public key into firefox, and have firefox consult the TLD list in the DNS, verified with DNSSEC, whenever information is needed? That way nobody can say that you have a software update problem. Yet you retain the autonomy you need to get a solution implemented quickly. If the solution proves out well, perhaps people will adopt it. Even if it doesn't, it can't possibly be worse than a list hard- coded into the software. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Yngve and Gerv, As you have no doubt concluded by now, you've touched a nerve. :) It doesn't seem to me that you have, but I hope that you will not interpret the strong reaction you've received as an attack. It's simply the case that what you're planning to do sounds (and in some ways is) painfully similar to other ideas that haven't worked out so well in the past, and you're dealing with a lot of people here who do not want to see history repeat itself. Coming as it does late in your development cycle (and especially given the enthusiastic reaction you've received here today) the temptation would be for you to dig your heels in and insist on moving forward as planned. I urge you to resist that temptation. I apologize if this sounds like self-aggrandizement, but I think I'm pretty well qualified to comment on your plan: 1. I dealt with almost all of the TLDs in my role as dns administrator for Yahoo!, and maintained a similar list of valid registration points there for several years. 2. My first job at Yahoo! was programming CGI apps, including domain name registration and authentication modules, both of which used cookies. 3. I used to manage the IANA, so I have a lot of experience working with the TLD operator community on various topics, including policy matters and updates to their records. All that said, I think that there is some merit in what you're trying to do. Such a list has utility (to the extent that it is kept up to date) and it would be nice to have that information collected in one location. In an ideal world that location would be ICANN (specifically IANA) but for a variety of reasons, some of which David already mentioned, that probably isn't possible at this time. I would like to refer you to one similar (although limited) resource that IS managed by IANA, the list of valid TLDs that we set up while I was there. It may help you at least update your current list, and help keep it up to date: http://data.iana.org/TLD/tlds-alpha-by-domain.txt When I was maintaining the list of valid registration points (IIUC what you're referring to as public suffixes) I was dealing with a limited number of TLDs, and received updates to the list roughly every week and a half or so. A lot of these updates were additions, which IIUC your software will handle as a soft fail if they are not present in the list already. More troublesome for the topic at hand is that roughly twice a month I received an update about a registry that had changed its policy, usually making it more permissive (i.e., adding additional registration points). Indeed, that has been the trend amongst virtually all of the TLDs since I started caring about this topic in 1998. There is also another issue which I haven't seen addressed, although admittedly it's a corner case, of TLD NICs that establish a firm policy preventing user registration at the top level, but allow themselves to operate sites such as www.nic.tld. I'm also not sure you quite understand the magnitude of the task you're undertaking. It's a matter of fact that any sentence including the phrase all TLDs is doomed from the start. :) You're dealing with a wide variety of business models (often with competing interests), policies, levels of technical ability, levels of operating capacity, and dare I say it, personalities. You will never get full cooperation, and as you can see by Stephane's response you will definitely irritate at least some of the TLD operators with this change. You might want to rethink socializing this concept before you launch. There is also the issue raised here by others already that new TLD introduction (and the corresponding churn on registration policies that will come as each new TLD matures) will soon become much, much more common. This will (IMO) be especially true of the new IDN TLDs. If this cookie security issue in particular is valuable, you do your users a disservice by treating new TLDs differently from old ones. One of the key features of the DNS is that it is supposed to work the same for everyone. What you're proposing places artificial, and immutable categorization into the name space that it is not only not designed, but I would say not intended to have. Now all THAT said, let's look at what you're planning to do. Leaving aside the nice to have stuff like history grouping, I'm very interested in your concerns about cookie policy. Is the threat you're trying to guard against (cookie collusion) something real that you've seen in action, or something that you perceive to be a potential threat? Please forgive my ignorance on this topic, it's been a while since I've had to deal with cookie issues. Others have already said that the proper place to deal with this is in the cookie spec, so I won't belabor that. Assuming that you are going to go forward with some form of this no matter what, I would urge you in the strongest possible terms to reconsider your plan to make it a static
Re: [DNSOP] Public Suffix List
At 3:02 PM -0700 6/9/08, Doug Barton wrote: I'm also not sure you quite understand the magnitude of the task you're undertaking. It's a matter of fact that any sentence including the phrase all TLDs is doomed from the start. :) You're dealing with a wide variety of business models (often with competing interests), policies, levels of technical ability, levels of operating capacity, and dare I say it, personalities. You will never get full cooperation, and as you can see by Stephane's response you will definitely irritate at least some of the TLD operators with this change. You might want to rethink socializing this concept before you launch. Directly related to this is Mozilla's TLD-based IDN settings that Kim Davies mentioned at http://www.ietf.org/mail-archive/web/dnsop/current/msg06140.html. If you go to the Mozilla page listed in that message, you will notice that a few TLDs that allow IDNs have not registered with Mozilla for various reasons (*cough* *cough* .com, .ru, .many-countries-in-the-arab-speaking-world, ...). This is reasonably good and local proof that Mozilla asking TLDs for information for this new registry is likely to result in incomplete information for many important TLDs. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
