ICANN opens up Pandora's Box of new TLDs

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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. :slight_smile: 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

5

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.

6

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. :slight_smile: 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.

7

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.

8

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 :frowning:

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

9

(picking up where I ejected on the email...argh)

10

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 :frowning:

Yes, sorry, DHS. :slight_smile: 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

11

Interesting, I was under the impression anything less than 120 is effectively as good as 120.

   Gadi.

12

I have not measured... I bet yahoo has though :slight_smile: and/or Akamai.
There's a reason that these folks are doing this. Would be an
interesting presentation though eh?

-Chris

13

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 :slight_smile: and/or Akamai.
There's a reason that these folks are doing this. Would be an
interesting presentation though eh?

Yep.

Any takers?

14

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.

15

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.

16

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.

17

Tony Finch 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

18

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.

19

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.