Re: ICANN opens up Pandora's Box of new TLDs
Phil Regnauld wrote:
As business models go, it's a fine example of how to build demand without really servicing the community.
Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis
On Jun 27, 2008, at 1:32 PM, Roger Marquis wrote:
Phil Regnauld wrote:
As business models go, it's a fine example of how to build demand without really servicing the community.
Of all the ways new tlds could have been implemented this has to be the most poorly thought out.
Oh, no. There are plenty of worse thought out approaches. _Plenty_.
Security-aware programmers will now be unable to apply even cursory tests for domain name validity.
I'm not sure how much I'd trust a 'security-aware programmer' that relies on top-level domain name labels for _anything_, much less domain name validity. But perhaps I misunderstand your point.
Phishers and spammers will have a field day with the inevitable namespace collisions.
I believe an attempt at limiting this is found in the restriction to disallow 'confusingly similar' names.
It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts.
I suspect you might not be fully aware of how ICANN works. ICANN is not the Internet's mommy and it can't make problems go away (even those it created itself) by waving a magic wand. It works via a bottom-up policy definition process that involves a large number of parties, many of which are directly at odds with each other. Efforts are underway in several of ICANN's constituencies and advisory councils to propose solutions to all of these (e.g., for domain tasting see http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113173) , but (as I have discovered painfully) it is exceedingly difficult to have rapid forward motion in such an environment. If you try, you get accused of acting in non-open, non-transparent, non-accountable, etc. ways by all sorts of people. Really.
[de rigueur ICANN bashing]
It is easy to criticize (trust me, I do it all the time :-)). It is more difficult to participate to try and get things fixed. Regards, -drc
On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis <marquis@roble.com> wrote:
Phil Regnauld wrote: apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts.
Please do not conflate: 1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info These are separate and distinct issues... I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses), Double-Flux (at least the traditional DF) isn't though certainly Akamai COULD do something similar to Double-Flux (and arguably does with some bits their services. The particular form 'Double-Flux' is certainly troublesome, but arguably TOS/AUP info at Registrars already deals with most of this because #4 in your list would apply... That or use of the domain for clearly illicit ends. Also, perhaps just not having Registrar's that solely deal in criminal activities would make this harder to accomplish... Botnets clearly are bad... I'm not sure they are related to ICANN in any real way though, so that seems like a red herring in the discussion. Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs... the fact that someone figured out that computers could be used to take advantage of that loophole on a massive scale isn't super surprising. In the end though, it's getting fixed, perhaps slower than we'd all prefer, but still.
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this? -chris
On Fri, 27 Jun 2008, Christopher Morrow wrote:
1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info These are separate and distinct issues...
They are separate but also linked by being issues that only be addressed at the registrar level, through TOS. Since some registrars have a financial incentive not to address these issues, in practice, they can be implemented only by ICANN policy (mandated much like the domain refund period).
I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses)
That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition...
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs...
The domain tasting policy was, if I recall, intended to address buyers of one to a few domains, not thousands. Would be a simple matter to fix, in a functional organization.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this?
Yes, sorry, DHS. :-) At least they are sensitive to security matters and would, in theory, not be as easily influenced by politics as was the NSF. Roger Marquis
On Fri, 27 Jun 2008, Roger Marquis wrote:
On Fri, 27 Jun 2008, Christopher Morrow wrote:
1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info These are separate and distinct issues...
They are separate but also linked by being issues that only be addressed at the registrar level, through TOS. Since some registrars have a financial incentive not to address these issues, in practice, they can be implemented only by ICANN policy (mandated much like the domain refund period).
These issues can be addressed, from a defensive standpoint alone, at: 1. The root 2. TLDs (the servers) 3. TLDs (registries) 4. Registrars 5. ISPs NS 6. Home, end-user The ability, sanity, cost and effectiveness are the main factors deciding what is to be done. Does anyone want a domain blocked at the TLD server under even extreme conditions? I do, but the situation would have to be *really* extreme, which I have only seen few of in the last 10 years. Registries have a high level of importance to this fight, especially if they are to make sure their business is not mostly criminally used--if they care. Registrars are far more closer to the fight, but with less potential impact--if they care, and we know some do. Others however are built to begin with as criminal havens.
I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses)
That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition...
You are both right. FF is a concept. I should know, having been the bastard to expose it to the public and thus getting it the defensive attention it needed--and wide(er) exploitation (I am not the one who found out it exists, that was someone who shall remain anonymous). The TTL is what is mainly abused. Then it went to the NS level, and I see no problem with NSs simply returning different answers with every query. I believe it has in fact been done before by the criminals.
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs...
The domain tasting policy was, if I recall, intended to address buyers of one to a few domains, not thousands. Would be a simple matter to fix, in a functional organization.
From a security standpoint.. But what it actually does is allow a criminal to register a domain, use it and dump it. Kind of like a jerk picking up a girl at a pub, if an analogy is easier for us to use. The main difference being domains don't get hurt, they just get replaced.
The only difference using tasting when replacing domains is that when bought with a fake credit card (which has no practical effect on how the criminals do business) the registrars need to handle it, and that costs money. The second, far more recongnized abuse, is financial and has to do with some registrars operational practices, and/or being somewhere between sound businesses to bastards, which is beyond the scope of this post.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this?
Yes, sorry, DHS. :-) At least they are sensitive to security matters and would, in theory, not be as easily influenced by politics as was the NSF.
You must be joking.
Roger Marquis
Gadi.
On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis <marquis@roble.com> wrote:
On Fri, 27 Jun 2008, Christopher Morrow wrote:
I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses)
That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition...
;; ANSWER SECTION: www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15 akamai, 60 second TTL's... most of the FF things I've seen sit around 300seconds for NS and for A records. either way, this is 60 seconds which is fast enough. http://en.wikipedia.org/wiki/Fast_flux that goes fairly well to what I was referencing as FF and Double-Flux.
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs...
The domain tasting policy was, if I recall, intended to address buyers of one to a few domains, not thousands. Would be a simple matter to fix, in a functional organization.
sure, policy by committee I think drc made some references to that process. It's taking time :(
Yes, sorry, DHS. :-) At least they are sensitive to security matters and would, in theory, not be as easily influenced by politics as was the NSF.
I'm not sure that a us-focused law/regulatory answer serves 'the tubes' very well. Certainly DHS can help make things useful inside the US-Govt. they may also be able to help advise, but implementation is left to the operators and policy folks in ICANN + registries + registrars. -Chris
On Sat, 28 Jun 2008, Christopher Morrow wrote:
On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis <marquis@roble.com> wrote:
On Fri, 27 Jun 2008, Christopher Morrow wrote:
I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses)
That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition...
;; ANSWER SECTION: www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15
akamai, 60 second TTL's... most of the FF things I've seen sit around 300seconds for NS and for A records. either way, this is 60 seconds which is fast enough.
Interesting, I was under the impression anything less than 120 is effectively as good as 120. Gadi.
On Sat, Jun 28, 2008 at 12:34 AM, Gadi Evron <ge@linuxbox.org> wrote:
On Sat, 28 Jun 2008, Christopher Morrow wrote:
On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis <marquis@roble.com> wrote:
On Fri, 27 Jun 2008, Christopher Morrow wrote:
I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses)
That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition...
;; ANSWER SECTION: www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15
akamai, 60 second TTL's... most of the FF things I've seen sit around 300seconds for NS and for A records. either way, this is 60 seconds which is fast enough.
Interesting, I was under the impression anything less than 120 is effectively as good as 120.
I have not measured... I bet yahoo has though :) and/or Akamai. There's a reason that these folks are doing this. Would be an interesting presentation though eh? -Chris
On Sat, 28 Jun 2008, Christopher Morrow wrote:
On Sat, Jun 28, 2008 at 12:34 AM, Gadi Evron <ge@linuxbox.org> wrote:
Interesting, I was under the impression anything less than 120 is effectively as good as 120.
I have not measured... I bet yahoo has though :) and/or Akamai. There's a reason that these folks are doing this. Would be an interesting presentation though eh?
Yep. Any takers?
-Chris
These issues are not separate and distinct, but rather related. A graduated level of analysis of membership in any of the sets of: 1: Recently registered domain. 2: Short TTL 3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists. 4: Invalid/Non-responsive RP info in Whois Create a pretty good profile of someone you probably don't want to accept traffic from. Conflation is bad, recognizing that each metric has value, and some correlation of membership in more than one set has even more value, as indicating a likely criminal node, is good. YMMV. I guess, if you have perfect malware signatures, code with no errors, and vigilance the Marines on the wire @ gitmo would envy, you can accept traffic from everywhere.
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Friday, June 27, 2008 7:23 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis <marquis@roble.com> wrote:
Phil Regnauld wrote: apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts.
Please do not conflate:
1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info
These are separate and distinct issues... I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses), Double-Flux (at least the traditional DF) isn't though certainly Akamai COULD do something similar to Double-Flux (and arguably does with some bits their services. The particular form 'Double-Flux' is certainly troublesome, but arguably TOS/AUP info at Registrars already deals with most of this because #4 in your list would apply... That or use of the domain for clearly illicit ends. Also, perhaps just not having Registrar's that solely deal in criminal activities would make this harder to accomplish...
Botnets clearly are bad... I'm not sure they are related to ICANN in any real way though, so that seems like a red herring in the discussion.
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs... the fact that someone figured out that computers could be used to take advantage of that loophole on a massive scale isn't super surprising. In the end though, it's getting fixed, perhaps slower than we'd all prefer, but still.
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this?
-chris
On Fri, 27 Jun 2008, Tomas L. Byrnes wrote:
These issues are not separate and distinct, but rather related.
A graduated level of analysis of membership in any of the sets of:
1: Recently registered domain.
2: Short TTL
3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists.
4: Invalid/Non-responsive RP info in Whois
Create a pretty good profile of someone you probably don't want to accept traffic from.
Conflation is bad, recognizing that each metric has value, and some correlation of membership in more than one set has even more value, as indicating a likely criminal node, is good.
YMMV.
I guess, if you have perfect malware signatures, code with no errors, and vigilance the Marines on the wire @ gitmo would envy, you can accept traffic from everywhere.
Not quite, because you still won't know who to send the Marines to kill. The Internet is perfect for plausible deniability. Gadi.
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Friday, June 27, 2008 7:23 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis <marquis@roble.com> wrote:
Phil Regnauld wrote: apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts.
Please do not conflate:
1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info
These are separate and distinct issues... I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses), Double-Flux (at least the traditional DF) isn't though certainly Akamai COULD do something similar to Double-Flux (and arguably does with some bits their services. The particular form 'Double-Flux' is certainly troublesome, but arguably TOS/AUP info at Registrars already deals with most of this because #4 in your list would apply... That or use of the domain for clearly illicit ends. Also, perhaps just not having Registrar's that solely deal in criminal activities would make this harder to accomplish...
Botnets clearly are bad... I'm not sure they are related to ICANN in any real way though, so that seems like a red herring in the discussion.
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs... the fact that someone figured out that computers could be used to take advantage of that loophole on a massive scale isn't super surprising. In the end though, it's getting fixed, perhaps slower than we'd all prefer, but still.
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this?
-chris
On Fri, Jun 27, 2008 at 11:13 PM, Tomas L. Byrnes <tomb@byrneit.net> wrote:
These issues are not separate and distinct, but rather related.
A graduated level of analysis of membership in any of the sets of:
1: Recently registered domain.
hi, I just registered 'newproduct.com' for my press release, I'm sending you emails from that domain since you signed up with my company for new news alerts abotu my great products!
2: Short TTL
I'm anticipating high traffic loads, I'm putting my pressrelease things on akamai/llnw, I want to shift that away quickly when traffic levels decrease. I made my ttl's short, for that, plus akamai sets my ttl's on their responses to 5mins.
3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists.
sure, these are fine folks... they get things wring at times :(
4: Invalid/Non-responsive RP info in Whois
oh, whois isn't updated with NS info updates... so for 6-12 hours that data's not going to reflect 'valid' info while I send out my notifications.
Create a pretty good profile of someone you probably don't want to accept traffic from.
I agree that correlation across many forms of intell gathering is good, and probably the way out for folks on the good side of this battle. My point was that tossing FUD on top of the 'icann made a mistake, maybe' isn't helping the argument nor discussion. There should be some work, and maybe there is work happening on this, done to bring ICANN policies up to speed with respect to dealing with: 1) domain owners who have invalid (chronically bad) info 2) registrars who seem to solely
Conflation is bad, recognizing that each metric has value, and some correlation of membership in more than one set has even more value, as indicating a likely criminal node, is good.
YMMV.
I guess, if you have perfect malware signatures, code with no errors, and vigilance the Marines on the wire @ gitmo would envy, you can accept traffic from everywhere.
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Friday, June 27, 2008 7:23 PM To: Roger Marquis Cc: nanog@nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs
On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis <marquis@roble.com> wrote:
Phil Regnauld wrote: apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts.
Please do not conflate:
1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info
These are separate and distinct issues... I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses), Double-Flux (at least the traditional DF) isn't though certainly Akamai COULD do something similar to Double-Flux (and arguably does with some bits their services. The particular form 'Double-Flux' is certainly troublesome, but arguably TOS/AUP info at Registrars already deals with most of this because #4 in your list would apply... That or use of the domain for clearly illicit ends. Also, perhaps just not having Registrar's that solely deal in criminal activities would make this harder to accomplish...
Botnets clearly are bad... I'm not sure they are related to ICANN in any real way though, so that seems like a red herring in the discussion.
Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs... the fact that someone figured out that computers could be used to take advantage of that loophole on a massive scale isn't super surprising. In the end though, it's getting fixed, perhaps slower than we'd all prefer, but still.
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community.
I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this?
-chris
(picking up where I ejected on the email...argh) On Sat, Jun 28, 2008 at 12:19 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, Jun 27, 2008 at 11:13 PM, Tomas L. Byrnes <tomb@byrneit.net> wrote:
These issues are not separate and distinct, but rather related.
A graduated level of analysis of membership in any of the sets of:
1: Recently registered domain.
hi, I just registered 'newproduct.com' for my press release, I'm sending you emails from that domain since you signed up with my company for new news alerts abotu my great products!
2: Short TTL
I'm anticipating high traffic loads, I'm putting my pressrelease things on akamai/llnw, I want to shift that away quickly when traffic levels decrease. I made my ttl's short, for that, plus akamai sets my ttl's on their responses to 5mins.
3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists.
sure, these are fine folks... they get things wring at times :(
4: Invalid/Non-responsive RP info in Whois
oh, whois isn't updated with NS info updates... so for 6-12 hours that data's not going to reflect 'valid' info while I send out my notifications.
Create a pretty good profile of someone you probably don't want to accept traffic from.
I agree that correlation across many forms of intell gathering is good, and probably the way out for folks on the good side of this battle. My point was that tossing FUD on top of the 'icann made a mistake, maybe' isn't helping the argument nor discussion.
There should be some work, and maybe there is work happening on this, done to bring ICANN policies up to speed with respect to dealing with: 1) domain owners who have invalid (chronically bad) info 2) registrars who seem to solely
solely registering bad/criminal/abusive domains... -chris
Roger Marquis (marquis) writes:
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community.
DHS ? Otherwise, yes, you could ship ICANN back to the US gvt. with DHL, but I don't think they'll give us our money back.
On Fri, Jun 27, 2008 at 01:32:05PM -0700, Roger Marquis <marquis@roble.com> wrote a message of 22 lines which said:
Security-aware programmers will now be unable to apply even cursory tests for domain name validity.
I am very curious of what tests a "security-aware programmer" can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs. If you test that the TLD exists... it will still work. If you test that the name matches (com|net|org|[a-z]{2}), then you are not what I would call a "security-aware programmer".
requiring valid domain contacts.
ICANN does require valid contacts. And it requires them to be published and sold. So, people lie to protect their privacy. In the world of security, stupid ideas often backfire.
I have to conclude that ICANN has failed, simply failed, and should be returned to the US government.
It never leaved it.
On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote:
I am very curious of what tests a "security-aware programmer" can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs.
It makes the "public suffix list" project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/ Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ SOUTHEAST FITZROY: VARIABLE 3 OR 4 BECOMING SOUTHWESTERLY 5 OR 6. MODERATE, BECOMING ROUGH LATER. RAIN LATER. GOOD BECOMING MODERATE.
Tony Finch wrote:
On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote:
I am very curious of what tests a "security-aware programmer" can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs.
It makes the "public suffix list" project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/
Tony.
Assuming O(1k) applications, and the numbers ICANN staff were using in February were 300 to 600, with the determining factors (a) existence of subsequent rounds and their temporal offsets, (b) actual application fee, originally guesstimated in the USD 100k range, now twice that, a sort of "self-imposed auction based on pain", or rumor mill run amok, depending on one point of view, and (c) the number of sunspots in the quarter that ICANN actually accepts applications; and application survival rates of 10% to 50% in the evaluation processes; then the root string insertion frequency may be as bounded above by 24 hours on average and below by 168 hours on average. It will be different. I pointed this out in the Registrar Constituency meeting in Paris Tuesday last, that our assumptions about the size of the registrars was already off by more than an order of magnitude, and our assumption about the size of the registries was about to fail as well, and that there were some additional non-scaling reasons to revisit the EPP design. Eric
On Mon, Jun 30, 2008 at 06:36:06PM +0100, Tony Finch <dot@dotat.at> wrote a message of 15 lines which said:
It makes the "public suffix list" project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/
Well, this list is a bad workaround for cookies specification problems and bad programming practices, so I'm not too concerned if it is perturbed.
On Tue, 1 Jul 2008, Stephane Bortzmeyer wrote:
On Mon, Jun 30, 2008 at 06:36:06PM +0100, Tony Finch <dot@dotat.at> wrote a message of 15 lines which said:
It makes the "public suffix list" project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/
Well, this list is a bad workaround for cookies specification problems and bad programming practices, so I'm not too concerned if it is perturbed.
I don't think bad programming can be blamed in this instance, and cookies are so widely used and so fundamentally broken that a workaround is the best way to improve their security. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FISHER GERMAN BIGHT: SOUTH BACKING SOUTHEAST 4 OR 5, OCCASIONALLY 6 LATER IN FISHER. SLIGHT OR MODERATE. FAIR. GOOD.
participants (9)
-
Christopher Morrow -
David Conrad -
Eric Brunner-Williams -
Gadi Evron -
Phil Regnauld -
Roger Marquis -
Stephane Bortzmeyer -
Tomas L. Byrnes -
Tony Finch