You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Reports from other days:

Saturday, 18 June 2011 Meetings
Sunday, 19 June 2011 Meetings
Tuesday, 21 June 2011 Meetings
Wednesday, 22 June 2011 Meetings
Thursday, 23 June 2011 Meetings
Friday, 24 June 2011 Meetings

Welcome Ceremony

Time: 09:00 - 10:30
Location: Canning/Padang
Author:

Please add your report here

ccNSO Tech Day

Time: 09:00 - 16:00
Location: Olivia
Author:

Please add your report here

Board Session - New gTLD Program

Time: 11:00 - 12:30
Location: Canning/Padang
Author:

Please add your report here

Joint ccNSO/GNSO Council Meeting

Time: 12:30 - 14:00
Location: Sophia
Author:

Please add your report here

Forum on DNS Abuse

Time: 13:00 - 14:30
Location: Canning/Padang
Author: Dev Anand Teelucksingh

Held in the large Raffles Ballroom, where hours earlier, the ICANN Board voted to approve the New gTLD Program.
In sharp contrast earlier, while the new gTLD Program Board meeting was packed, the room was relatively empty (about 100 persons) as the first panel went on stage and began the DNS Abuse Forum.
Jeff Moss, ICANN Chief Security Officer, opened the session as moderator of the DNS Abuse Forum
, the 6th such Forum at an ICANN meeting and introduced the first panel which is a disscussion
between the ICANN stakeholders (commercial, govt, consumers, businesses) about fighting DNS abuse. 
The first panel speakers were:
- Bill Smith from PayPal,
- Edmon Chung from APRALO and dot Asia, 
- Kai Koon Ng from Symantec.
Bill Smith from Paypal gave his presentation
"Combatting Cybercrime, Principles, Policies and Programs". 
- Asked how many persons in audience use a wireless router at home or work. Most indicated by show of hands that they do.
- His focus was on cybercrime involving "direct theft" 
(stealing or loss of money via DDOS attacks, malware, phishing, NOT intellectual property theft, terrorism, espionage, warfare. 
- The Problems:
- trust is easy to break, but harder to re-establish.
- Malware and Insecure Computers - both are individual and system wide vulnerabilities
- Obstacles to Effective Law Enforcement - More resources need to be invested in law enforcement, and better international cooperation
- Obstacles to Private and Public/Private Cooperation  - due to countries' privacy laws makes it difficult for companies to share data that could protect consumers/users
- Individual Rights and Obligations
- Unreliable Data on Scope and Scale of the Problem    - It is growing, but is the data collected showing increasing scale of issue an actual increase in malware evolution, or better reporting and data collection? Its both.
   
Principles of initiates:
1.Involve the least regulatory change needed to accomplish appropriate levels of safety
2. Ensure that laws can be interpreted in ways which credibly allow participants to prioritize safety 
eg. a safe harbour for companies to share data to protect customers/users
3. Make changes which reduce negative externalities in the overall ecosystem - this was skipped in the discussion
4. Accept that the Internet is is global – change is needed in every country, using compatible conceptual frameworks - bring multilateral assistance treaties in the 21st century. Data exchanged between nations can take months or years to take place - too long to help the situation. 
5. Avoid attempts to conflate other related issues, such as: intellectual property theft, free speech rights, privacy, etc. - not that these issues aren't important, but focus! 
6. In general, governments should not mandate nor manage technical controls - Govts should describe the effect that they want, instead. Static issues like vaccines in medicine, specifying specific control may have been straightforward. But cybercrime is dynamic with determined bad guys that alter their tactics and techniques. But if the goal is to stop a specific behaviour, then multiple approaches and methods can be deployed. For example, domain tasting 
7. Find solutions which improve security, without compromising privacy
8. Full anonymity on the Internet for e-commerce and financial transactions is often infeasible in today’s environment
9. Treat data usage for anti-fraud/crime purposes as distinct from data usage for marketing purposes
-  data that used for marketing purposes should be treated differently than data used for anti-crime/anti-fraud purposes. Paypal, for example, tracks information about users in order to make their own risk assessments and to improve their consumer's experience and to help with fraud and criminal activity.
10. Organizations that perform Internet Governance are part of the solution, not part of the problem
- three parts of ICANN - the multi-stakeholder that everyone participates, there is ICANN, the corporation and then ICANN the staff.
INITIATIVES
- the US has the National Transportation Safety Board
this industry could benefit from such a model (not mentioned on slides - futher thought - don't CERTs do this type of function?)
* Substantially improve consumer education on CyberSecurity - In Austraila the AISI(?) model is used to allow ISPs to notify customers of malware activity on their PCs.

Charter an organization to directly attack botnets
-  ISPs could also screen for and block botnet activity
- perhaps use vulnerabilities to attack the bad guys botnets
Drag MLATs out of the 19th century into the 21st

Create an international law enforcement model that allows for prosecution without requiring extradition

Require that Internet devices “fail safe” - referencing his earlier show of hands who used wireless routers, Wireless routers should not have default passwords but something unique since many do not change the defaults.

Force unsupported devices off the Internet - this wasn't explained during the presentation, but in a chat after the ALAC/WHOIS RT meeting (Bill being on the WHOIS RT), he explained this meant not having computers with older OSes (Win98 for eg) not go on the net, due to their vulnerabilities and that no software fixes by the OS maker are no longer forthcoming.
 
Take enforcement action against “bulletproof hosters”
(see

http://en.wikipedia.org/wiki/Bulletproof_hosting)&nbsp

;

Have SLAs for hosting companies to remove phish/malware sites

Create safe ways for companies to share information about compromised customers, which are exempt from normal rules

Ensure that ICANN properly enforces ecosystem safety initiatives (for example dealing with WHOIS)
Next Edmon Chung talked about dot Asia 
DNS Abuse Prevention Mechanisms
- many of the policies dot Asia put in place (sunrise policies) are now being put in the new gTLD discussions
* with Afilias as the back end provider helped dot Asia with the technical capability to deal with DNS abuse and phishing attacks
• Policy-wise, dot Asia worked with the APWG (Anti-Phishing WG) on predictable mechanisms to take down domains and/or sites with phishing activities.
• MPAA MoU - MOU with the MPAA that do something similiar to the URS to quickly take down domains with movie content, especially during the opening weeks when the movie is showing in theaters.
* worked with AP CERT & HK CERT and done practice drills for sceanarios
 
• extensive use of Sunrise Mechanisms for dot Asia and is using that experience for its IDN TLD. Also deal with the variant issues as per their IDN variant policy. A detailed illustration was shown in the slides (page 18 of the 93 page PDF)
* working with CHIP (Clearinghouse for Intellectual Property), for the sunrise verification and preverification processes and a trademark claims service (being discussed in the new gTLD program) after the the sunrise period. 
- using such expertise to help the Macao (.mo) 
govt
ISOC Hong Kong has worked on security and privacy as this is the #1 issue for At-Large as well as security issues related to IPv6 and Green Dam (

http://en.wikipedia.org/wiki/Green_Dam_Youth_Escort

)
ISOC Hong Kong has a WG on security and privacy and is trying to balance those issues. The dilemna is that while users think they want security and privacy, there are tradeoffs or compromises. Eg. dot CN requires real name for domain registration which increases security, but with loss of privacy.
Note : see link at

http://dl.dropbox.com/u/877052/ICANN-Singapore/Monday/dns-abuse-forum-report.txt

due to the length and the difficulty in inserting the text

FY12 Draft Operating Plan and Budget

Time: 13:30 - 14:30
Location: Orchard A/B
Author:

Please add your report here

New gTLD Update

Time: 14:30 - 16:00
Location: Canning/Padang
Author:

Please add your report here

GAC Meeting with SSAC

Time: 15:00 - 16:00
Location: Collyer
Author:

Please add your report here

DNSSEC for Everybody - A Beginners Guide

Time: 16:00 - 17:30
Location: Olivia
Author:  Darlene Thompson

DNSSEC for Everybody:  A Beginners Guide

DNSSEC continues to be deployed around the world at an ever accelerating pace. From the Root, to both Generic Top Level Domains (gTLDs) and Country Code Top Level Domains (ccTLDs), the push is on to deploy DNSSEC to every corner of the internet. Businesses and ISPs are building their deployment plans too and interesting opportunities are opening up for all as the rollout continues.

In the beginning of this presentation, DNSSEC was cleverly illustrated through simple cartoons of cavemen.  Later, a series of (low budget but hilarious) scits were put on to illustrate DNSSEC and how and how it prevents malicious attacks.  This session really made DNSSEC easily understood.  Points that were raised:

DNS Security
• DNS has no security
• One packet for query, one packet for response
• Must rely on source IP‐based authentication
• Easily spoofed
• Clever resolvers help a lot
• But we need something better

What DNSSEC Does
• DNSSEC uses public key cryptography and digital signatures to provide:

  • Data origin authentication
    • “Did this DNS response really come from the .com zone?”
  • Data integrity
    • “Did an attacker (e.g., a man-in-the-middle) modify the data in this response since it was signed?”
    • Bottom line: DNSSEC offers protection against spoofing of DNS data

    What DNSSEC Doesn’t Do
    • DNSSEC does not:
  • Provide any confidentiality for DNS data
    • I.e., no encryption
    • The data in the DNS is public, after all
  • Address attacks against the name server itself
    • Denial of service,
    • Packets of death,
    • etc.

    Key Pairs
    • In DNSSEC, each zone has a public/private key pair
    • The zone’s public key is stored in the new DNSKEY record
    • The zone’s private key is kept safe
  • Stored offline (ideally)
  • Perhaps held in an HSM (Hardware Security Module)

    Digital Signatures
    • A zone’s private key signs each piece of DNS data in a zone
    • Each digital signature is stored in an RRSIG record

    Chain of Trust
    • There are no certificates in DNSSEC
    • The trust model is rigid
    • The chain of trust flows from parent zone to child zone
    • Only a zone’s parent can vouch for its keys’ identity

    Types of Keys
    • Signed zone has DNSKEY records at its apex* Usually multiple keys* One or more key-signing keys (KSKs)* One or more zone-signing keys (ZSKs)• KSK
  • Signs only the DNSKEY records• ZSK
  • Signs the rest of the zone

    Delegation Signer (DS) Records
    • The Delegation Signer (DS) record specifies a child zone’s key
    • A zone’s DS records only appear in its parent zone
    • DS records are signed by the parent zone

    Trust Anchors
    • You have to trust somebody
    • DNSSEC validators need a list of trust anchors
    • A trust anchor is a key that is implicitly trusted
    • Analogous to list of certificate authorities (CAs) in web browsers

    DNSSEC Implementation Samples
    • DNSSEC implementation depends upon & is mostly driven by an activity’s DNS
    functions
  • DNS is made up of many parts, e.g., name server operators, applications users, name holders (“owners”), DNS provisioning
  • Activities with large, complex DNS functions are more likely to have more complex DNSSEC implementation activities• Also more likely to have ‘DNS knowledgeable’ staff
    • DNS size and complexity examples:
  • Registry responsible for a large TLD operation, e.g., .com
  • Substantial enterprise with many components with many geographic locations, e.g., hp.com
  • Internet-based businesses with a number of business critical zones, e.g., www.verisign.com
  • Activities with non-critical DNS zones, e.g., net-snmp.org
  • Proverbial Internet end users (all of us here)

    General Principle:
    • If an activity does a lot with their DNS functions and operations then they probably will want to do a lot with the associated DNSSEC pieces;
    • If an activity does little or nothing with their DNS functions and operations then they probably will want to do little or nothing with the associated DNSSEC pieces.

    DNS Basic Functions
    • DNS provides the translation from names to network addresses
    • Get the right DNS content to Internet users
    -->IT’S DNS CONTENT THAT MATTERS!

    How Does DNSSEC Fit?
    • DNSSEC is required to thwart attacks on DNS CONTENT
    • DNS attacks used to attack Internet users applications
      -->Protect DNS CONTENT as much as (or more than) any DNSSEC information
      -->Including DNSSEC private keys!!

IDN Varaint TLD

Time: 16:00 - 17:30
Location: Canning/Padang
Author:

Please add your report here

Joint ccNSO/GNSO IDN Working Group (JIG)

Time: 17:30 - 18:30
Location: Moor
Author:

Please add your report here

  • No labels