At-Large Beijing Meeting Reports Workspace

• Report on New gTLD SSR Update by SSAC Liaison
• The Audiocast of the Session can be found at http://beijing46.icann.org/node/37057

General Points

• IANA is ready to process delegations wef 1May.  
• Growth of traffic in the root zone is not really dependent on the no of TLDs. The change on the size of the root zone will not be as big as some previous changes (eg deployment of DNSSEC in 2010).
• L-root has been collecting some metrics (wef 3 Apr) so that long term trends can be observed i.e. they are establishing the baseline.

Discussion on SAC057 - Internal Name Certificates

Certificate Authorities (CAs)

• Not all CAs are members of the CA/Browser Forum and may not abide by Ballot 96. (See Supplementary Note)
• Even if they do, there will still exist a vulnerability window because of the 120 days (Ballot 96).
• We don't really know what certificates have been issued for these internal name servers.

Browser Vendors

• ICANN Security Team is working with Browser Vendors on this issue. Some browsers do not check for revocation of certificates.
• Part of Solution might be to use DANE and sign with DNSSEC.
• Options being considered by browser vendors to address this will only be applicable to latest versions and there will still be many older browser versions in use.

Other Applications

• Browsers are not the only applications used to connect to the internet. There are a number of other protocols that rely on Certificates. The traffic is not all web queries.
• Some applications don't support renovation checking at all, or a man-in-the-middle attack can stop the revocation from happening.
• One mitigation is to ask server manufacturers to turn on OCSP Stapling by default (On-Line Certificate Status Protocol).  This would ensure that revocation status would be checked.
• There may be other complex interactions between the DNS and other applications at the root level, cross application issues, which need to be explored.  SSAC has been asking for interdisciplinary studies on these issues and ICANN may need to act as coordinator/facilitator/collaborator on these.

Other Issues and Concerns

• Irrespective of the case where certificates already exist for yet to be released gTLDs, there is also a problem associated with internal network configurations which utilise these names with or without certificates at the second or third levels eg example.com where .example is an applied for new gTLD. Queries to these new gTLDs may be directed to these internal networks, causing problems for businesses, consumers and end users.  It was observed that ISPs will likely bear the brunt of complaints if this occurs and possibly  incur significants costs in customer support that is unrelated to their core services.

Letter from Paypal

• Letter identified their concern about 'significant security issues related to  delegating gTLDs that are currently in wide use as de facto private TLDs'. They state the top 10 of these represent 10% of the total query load at the root servers.  The top 13 invalid queries some of which are gTLD suffixes identified in RFC6762 are:
  
  • .invalid .wpad  .home  .belkin  .corp  .lan  .domain  .localdomain .localhost  .local  .intranet  .internal   .private
• This was highlighted in SAC045 - Invalid Top Level Domain Queries at the Root Level.  Recommendations were made in that report to mitigate this risk.

New Measurements

• SAC057 is based on data from August 2010. One member of the community has collected similar but not identical data since the release of SAC057. They examined only web queries in the .com and .net TLDs, looking for IPs that are pointed to by DNS names.  Although the results are not comparable, they found that there are some 25 million certificates associated with 51 applied for new gTLDs, the biggest being .corp with 102 unique sub-domains.
• The top 4 in order of size were:
  
  • .corp   .home   .offline   .inc
• Others that are also commonly found are:
  
  • .site   .mail   .bank  .ads  (active directory service)

Conclusion

There was a call to the community to identify any other issues and concerns which should be addressed in relation to new gTLDs.

Supplementary Note

Mozilla has a Network Security Services (NSS), a set of libraries designed to support cross-platform development of security-enabled client and server applications. This library provides a complete open-source implementation of the crypto libraries used by AOL, Red Hat, Sun, and other companies in a variety of products, including the following:

• The Mozilla client products, including Mozilla Suite, Firefox, and Thunderbird.
• The Netscape browsers
• AOL Communicator and AOL Instant Messenger (AIM)
• Open source client applications such as Evolution, Gaim, and OpenOffice.org 2.0.
• Server products from Red Hat: Red Hat Directory Server, Red Hat Certificate System, and the mod_nss SSL module for the Apache web server.
• Server products from the Sun Java Enterprise System, including Sun Java System Web Server, Sun Java System Directory Server, Sun Java System Portal Server, Sun Java System Messaging Server, and Sun Java System Application Server.

At the SSAC Public Meeting in Beijing (0800-0900 Thursday 11Apr12), it was revealed by a member of the CAB Forum that recently Mozilla started the process to adopt the gTLD requirements (ballot 96).  Once Mozilla adopts it, the requirement will be binding on all CAs (in NSS), regardless of whether they are CAB Forum members.

When typing a name in a browser for example, that name must be first translated into a number by a system before the connection can be established. That system is called the Domain Name System (DNS) and it translates names like www.icann.org into the numbers – called Internet Protocol (IP) addresses. ICANN coordinates the addressing system to ensure all the addresses are unique.

DNSSEC   (DNS Security Extension) is a technology to secure the Domain Name System.

During this session, the panelist presented through a sketch a scenario where user is redirected to another website pretending that it is the one he is looking for when there is a security problem.  DNNSEC can be implemented by any individual or organization who is handling a Domain name System server or simply a name server.

Another session for a half day workshop is scheduled for April 10, 2013.  

Thick Whois GNSO Working Group (providing the GNSO Council with a policy recommendation on universal ‘thick’ Whois) looking at the following elements: response consistency, stability, accessibility, impact on privacy and data protection, cost implications, synchronization and migration, authoritativeness, competition in Registry services, existing WHOIS applications, data escrow and Registrar Part 43 WHOIS requirements.

Began with a brief explanation of what ‘thick’ and ‘thin’ whois means. For thick, registrar collects data on the registrant, the domain and various contacts, and provides the information to the registry. For thin registries, only the domain data published – but all three data types retained. The WG has reached consensus on most issues – but not all. 

The issue for this session: privacy. Specifically, looking at the privacy implications for the Registrants who have registered their information in the thin model with the expectation that only domain data would be captured at the Registry during a transitional period where they’ve registered their name in a jurisdiction where there are strong privacy protections in local law? And now that data is going to be published in a Registry where the local law is different. The issue for registrants may arise if they deal with a registrar in a ‘privacy-friendly’ country with strong privacy laws, but the registry is in a jurisdiction with far less stringent privacy laws and registrant data is then made publicly available when all registries are ‘thick’.

Middle East Strategy : The meeting talked to strategies that are being worked on to improve achieve three goals:

• Foster two-way engagement between ICANN and the broader Internet community in the region;
• Build strong and competitive domain name industry in the region;
• Promote multistakeholder Internet governance mechanisms in the region.
• Strategic Focus areas are:
• DNS security and stability
• Domain name industry
• Internet governance ecosystem

In comments, the CEO of AusRegistry made suggestions including the need for metrics (such as number/percentage of registrations per population, registrations for businesses, number of gTLDs, ccTLDs, and talked of the need to promote local content as a driver.

Multi-Stakeholder Roundtable:

First session was on the new gTLDs. Speakers included Jeremy Malcolm, Consumers International, Peter Nettlefold, ViceChair, GAC, Zahid Jamil, Business Constituency, GNSO, Maguy Serad, ICANN Compliance.

Malcolm: Focus on end users- names they use, not have. Issues for consumers include the possibility of phishing, software incompatibilities, unclear expectations from the new names. Overall, the impact is likely to be relatively minor – a don’t know, don’t care attitude.

Nettlefold: Taken the view that they aren’t keen to object outright, but concerns include issues of defensive registrations, whether there is an implied level of trust with strings. On PICS, there was a need to identify the goal of commitments made in applications.

On compliance, there are issues of enforceability, who can raise concerns, who is notified, and what are the enforcement mechanisms.

Jamil: Are three stakeholders: the end user, the registrant and the trademark holder. All three should be protected. It is important that confusion is avoided, includingwhether there are IP risks attached to the name. What about scripts other than ASCII, and what about words that are similar? – is nothing in the Trade Mark clearing house to deal with those issues. On PICS, the current obligations are on registries – but what about registrars. Further, the RAA akkiws a oattern of abuse, with no mechanism to deal with it. Finally, developing countries do not have mechanisms to deal with the issues and maya become soft targets.

Serad: Compliance has been identifying the gaps in PICS and are building a readiness plan. There will be proactive monitoring for compliance. On enforceability, there is a lack of clarity on whether they are contractual obligations.

Rapport_Constituent Stakeholder Travel Guidelines

Whois Working Group

Review of documents published

Since then, have been additional negotiations, and has been agreement in principle to additional issues

Cautions:

• Has been a 4year process and there is a level of anxiety about the final text
• The specification on privacy/proxy has been condensed
• What about verification of the true registrant using a privacy/proxy service

Report_ICANN Finance Open Session.pdf

Engagement with RIRs – especially APNIC – be aware of events involving RIRs

• New groups, including new gTLD outreach
• Need for feedback on ATRT2
• Is survey on ICANN image
• Is a need for a youth session or youth forum as a bridge between users and ICANN
• Need for briefing sessions
• Issue of individual membership
• Elections: (for APRALO Chair – Holly’s term ends 30 June, for APRALO Vice Chair (YJ’s term ends 30 June) and for Secretariat – Edmon and Pavan – term ends 30 June)
  
  • Nominations are from 9 April to 3 May
  • 4 May – 10 May – acceptances by nominees
  • 17 May – 7 June: Elections
  • 1 July – Newly elected leaders’ terms begin

Report_Global Stakeholder Engagement.pdf

11 April 2013, 09:00-10:30

Members of the MSWG Group:

This was the first meeting of the Meeting Strategy Working Group (MSWG). It was mostly an introductory meeting. The agenda was as follows: 

1.Welcome

2.Composition

3.Goals

4.Deliverables

5.Organization

6.Schedule

7.AOB (any other business)

Please check here for more details: https://community.icann.org/download/attachments/40929548/ICANN_MSWG_Beijing_2013_04_11_fin+%283%29.pdf?version=1&modificationDate=1367251475241

The next meeting will be a telephone conference to be held May 2, 2013 @ 1400UTC. The group agreed to have these calls every two weeks going forward.

This was one of the final meetings of the WG.

The Study Group was established by a resolution of the ccNSO Council on 8 December 2010. The Study Group was tasked with developing an overview of:

• the way in which the names of countries and territories are currently used within ICANN, be it in the form of policies, guidelines and/or procedures;

• the types of strings, relating to the names of countries and territories that currently used, or proposed to be used, as TLDs; and

• the issues that arise (or may arise) when current policies, guidelines and procedures are applied to these representations of country and territory names. 

The Study Group is comprised of representatives from across the ICANN stakeholder community and has been conducting its work since May 2011.

A Final draft report was discussed and will be shortly presented to the public for comments.

Final draft recommendations from the group are:

• The ccNSO Council is recommended to request the Board to extend the current rule in the Applicant Guidebook to exclude all country and territory names in all languages, for consecutive rounds of new gTLD applications.
• It is further recommended that the ccNSO Council takes the initiative to establish a cross community working group to review the current definitions of country and territory names under current policies and propose a consistent and uniform definition that should be applicable across the respective SO’s and AC’s. The GNSO, ALAC and GAC should be invited to participate in such a WG.

Please check meeting transcript here: Transcript Country Names Beijing.pdf and final draft report here: 2012-03 ccNSO Study Group on Country and Territory Names -Final Report v02.docx