ICANN ICANN Email List Archives

[idn-discuss]


<<< Chronological Index >>>    <<< Thread Index >>>

[idn-discuss] IDNccTLD security

  • To: idn-discuss@xxxxxxxxx
  • Subject: [idn-discuss] IDNccTLD security
  • From: JFC Morfin <jefsey@xxxxxxxxxx>
  • Date: Sat, 02 Jun 2007 17:25:57 +0200

A debate has started on the ccTLD list about the security of IDNccTLDs.

When you think of it, there are many documents, mails, etc. about antiphishing protection by TLDs at 2nd level (IANA Tables), at 3rd+ level (through browser based solutions for example). However, I do not recall top level having been discussed? The cyberattack on Estonian shows what could happen permanently to a national Internet community with a security hole in its TLD.

I think this rises some questions such as:
- security of the xn--tended TLDs (in the NS and DNAME cases): is there a possible problem (WG-IDNA did not consider IDNTLD)?
- the responsibility of their choice. Insurances refuse to cover this kind of risk, would ICANN or ccNSO do?
- which protection solution could be proposed?


I am interested in doing some practical study of what browser interrelation with an protection OPES (Open Pluggable Edge Services - RFC 3238, 3752, 3835, 3836, 3837, 3897, 3914, 4037, 4236, 4496, 4902) and multi-level naming (*) could offer. I would thank anyone who could point out an IDNA extension or a plug-in, possibly in C, that I could easily play with and compile under Windows for some quick and dirty exploration, on the application side. This might be adequate to the preparation of the San Juan June 23rd meeting on the ccNSO/GAC issues.

Further on, I understand there is an OPES Java implementation that could be used (but I am no Java developer).
jfc


(*) I call multi-level naming, in a similar way to multi-level addressing, when you must enter several successive or parallel DDDS's (plug-in, OPES, DNS, etc.) to resolve the final address.









<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy