Please add your report here

Please add your report here

Please add your report here

Please add your report here

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 began his presentation "Combatting Cybercrime, Principles, Policies and Programs" by asking 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, according to Bill.Principles of initiates:# Involve the least regulatory change needed to accomplish appropriate levels of safety# 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

1. Make changes which reduce negative externalities in the overall ecosystem - this was skipped in the discussion
2. 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. 
3. 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! 
4. 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 
5. Find solutions which improve security, without compromising privacy
6. Full anonymity on the Internet for e-commerce and financial transactions is often infeasible in today’s environment
7. Treat data usage for anti-fraud/crime purposes as distinct from data usage for marketing purpose - 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.
8. Organizations that perform Internet Governance are part of the solution, not part of the problem - there are three parts of ICANN - the multi-stakeholder that everyone participates, there is ICANN, the corporation and then ICANN the staff.
   

Please add your report here

Please add your report here

Please add your report here

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!
    

Please add your report here

Please add your report here