FW: [GAC] Draft GAC letter to ICANN re LEA Due Diligence and RAA amendment proposals
Please note the attached letters to ICANN as submitted by Janis recommending "Endorsement of the "Law Enforcement Recommended Amendments to ICANN's Registrar Accreditation Agreement (RAA) and Due Diligence Recommendations"". Glen - Please forward these to the RAA WG. Chuck ________________________________ From: Janis Karklins [mailto:janis.karklins@icann.org] Sent: Monday, April 12, 2010 1:41 PM To: peter.dengatethrush@icann.org Cc: 'ICANN Board ICANN Board List'; gac@gac.icann.org; Gomes, Chuck Subject: FW: [GAC] Draft GAC letter to ICANN re LEA Due Diligence and RAA amendment proposals Dear Peter, In the Nairobi Communiqué the GAC committed to send to ICANN the G8, Interpol and COE Octopus statements of support for the law enforcement agencies' proposals. In this respect, pls find attached the GAC letter and corresponding annexes: · Interpol Working Party on IT Crime-Europe Statement · G8 Lyon-Roma Group High Tech Crime Subgroup Statement · Council of Europe Project on Cybercrime, "Messages from the Octopus Conference" Best regards JK
Not sure where the original law enforcement document was submitted. Below is what I found at: https://st.icann.org/raa-related/index.cgi/LawEnforcementRAArecommendations%.... Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Introduction: Below are: 1) suggested amendments to the RAA and; 2) due diligence recommendations for ICANN to adopt in accrediting registrars and registries. Both are supported by the following international law enforcement agencies: • Australian Federal Police; • Department of Justice (US); • Federal Bureau of Investigation (US); • New Zealand Police; • Royal Canadian Mounted Police; • Serious Organised Crime Agency (UK) The amendments are considered to be required in order to aid the prevention and disruption of efforts to exploit domain registration procedures by Criminal Groups for criminal purposes. The proposed amendments take account of existing EU, US, Canadian and Australian legislation and those countries commitment to preserving individual’s rights to privacy. These amendments would maintain these protections whilst facilitating effective investigation of Internet related crime. I. Proposed Amendments to the RAA (May 21, 2009 version) ======================================================== 1) The RAA should not explicitly condone or encourage the use of Proxy Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN signed with the United States Department of Commerce on September 25, 2006 which specifically states “ICANN shall continue to enforce existing (Whois) policy”, i.e., totally open and public WHOIS, and the September 30, 2009, Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information.” Lastly, proxy and privacy registrations contravene the 2007 GAC Principles on WHOIS. If there are proxy and/or privacy domain name registrations, the following is recommended concerning their use: a. Registrars are to accept proxy/privacy registrations only from ICANN accredited Proxy Registration Services;1 (1: ICANN to implement accreditation system for Proxy Services using the same stringent checks and assurances as provided in these points, to ensure that all proxy services used are traceable and can supply correct details of registrant to relevant authorities.) b. Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity. 2) To RAA paragraph 5.3.2.1, language should be added to the effect “or knowingly and/or through gross negligence permit criminal activity in the registration of domain names or provision of domain name WHOIS information…” 3) All Accredited Registrars must submit to ICANN accurate and verifiable contact details of their main operational and physical office location, including country, phone number (with international prefix), street address, city, and region, to be publicly disclosed in ICANN web directory. Address must also be posted clearly on the Registrar's main website. Post Office boxes, incorporation addresses, mail-drop, and mail-forwarding locations will not be acceptable. In addition, Registrar must submit URL and location of Port 43 WHOIS server. 4) Registrars must publicly display of the name of CEO, President, and/or other responsible officer(s). 5) Registrars with multiple accreditations must disclose and publicly display on their website parent ownership or corporate relationship, i.e., identify controlling interests. 6) Registrar must notify ICANN immediately of the following and concurrently update Registrar website: a. any and all changes to a Registrar’s location; b. changes to presiding officer(s); c. bankruptcy filing; d. change of ownership; e. criminal convictions ; f. legal/civil actions 7) Registrar should be legal entity within the country of operation, and should provide ICANN with official certification of business registration or license. 8) Resellers must be held completely accountable to ALL provisions of the RAA. Registrars must contractually obligate all its Resellers to comply and enforce all RAA provisions. The Registrar will be held directly liable for any breach of the RAA a Reseller commits in which the Registrar does not remediate immediately. All Registrar resellers and third-party beneficiaries should be listed and reported to ICANN who shall maintain accurate and updated records. 9) Registrars and all associated third-party beneficiaries to Registrars are required to collect and securely maintain the following data (Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (i) Source IP address (ii) HTTP Request Headers (a) From (b) Accept (c) Accept‐Encoding (d) Accept‐Language (e) User‐Agent (f) Referrer (g) Authorization (h) Charge‐To (i) If‐Modified‐Since (iii) Collect and store the following data from registrants: (a) First Name: (b) Last Name: (c) E‐mail Address: (d) Alternate E‐mail address (e) Company Name: (f) Position: (g) Address 1: (h) Address 2: (i) City: (j) Country: (k) State: (l) Enter State: (m) Zip: (n) Phone Number: (o) Additional Phone: (p) Fax: (q) Alternative Contact First Name: (r) Alternative Contact Last Name: (s) Alternative Contact E‐mail: (t) Alternative Contact Phone: (iv) Collect data on all additional add‐on services purchased during the registration process. (v) All financial transactions, including, but not limited to credit card, payment information. 10) Each registrar is required to validate the following data upon receipt from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (1) Technical Data (a) IP addresses used to register domain names. (b) E‐mail Address (i) Verify that registration e‐mail address(es) are valid. (2) Billing Data (a) Validate billing data based on the payment card industry (PCI standards), at a minimum, the latest version of the PCI Data Security Standard (DSS). (3) Contact Data (a) Validate data is being provided by a human by using some anti‐automatic form submission technology (such as dynamic imaging) to ensure registrations are done by humans. (b) Validate current address WHOIS data and correlate with in‐house fraudulent data for domain contact information and registrant’s IP address. (4) Phone Numbers (i) Confirm that point of contact phone numbers are valid using an automated system. (ii) Cross validate the phone number area code with the provided address and credit card billing address. 11) Registrar must provide abuse contact information, including the SSAC SAC 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of Contact, 25 February 2009): • Registrars must prominently publish abuse contact information on their website and WHOIS. 1. The registrar identified in the sponsoring registrar field of a Whois entry should have an abuse contact listed prominently on its web page. To assist the community in locating this page, registrars should use uniform naming convention to facilitate (automated and rapid) discovery of this page, i.e., http://www.<registar>.<TLD>/abuse.html. 2. Registrars should provide ICANN with their abuse contact information and ICANN should publish this information at http://www.internic.net/regist.html. • The information a registrar publishes for the abuse point of contact should be consistent with contact details currently proposed as an amendment to Section 3.16 of the RAA. Each contact method (telephone, email, postal address) should reach an individual at the Registrar who will be able to promptly and competently attend to an abuse claim; for example, no contact should intentionally reject postal or email submissions. • Registrars should provide complainants with a well-defined, auditable way to track abuse complaints (e.g. a ticketing or similar tracking system). 12) ICANN should require Registrars to have a Service Level Agreement for their Port 43 servers. II. Proposed ICANN Due Diligence on current and new gTLD Registrars and Registries ================================================================================== a. ICANN to conduct enhanced due diligence on all Registrars and Registries (including but not limited to owners, officers, board of directors) ICANN accredits, or has accredited, to include, but not limited to: • criminal checks; • credit checks; • financial history and solvency; • corporate/company structure and ownership. For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc. b. Such due diligence shall be documented by ICANN, in detail, in a written report that can be provided upon request to appropriate auditors. c. ICANN should provide complainants with well-defined and auditable way to track complaints against Registrars and Registries. i. ICANN should publish annual detailed reports of reported complaints. d. ICANN should conduct WHOIS compliance audits, at least once a year, and publish results on: i. Port 43 ii. WHOIS accuracy
Thanks, Bruce. They were originally proposed at one of the Monday afternoon malicious conduct sessions during the Seoul meeting. The meeting "node" doesn't have the presentation, which I recall was somewhat broader (albeit less specific) than below. If anyone can point me in the right direction, I'd appreciate it. -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bruce Tonkin Sent: Tuesday, April 13, 2010 1:14 AM To: GNSO Council Subject: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Not sure where the original law enforcement document was submitted. Below is what I found at: https://st.icann.org/raa-related/index.cgi/LawEnforcementRAArecommendations%.... Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Introduction: Below are: 1) suggested amendments to the RAA and; 2) due diligence recommendations for ICANN to adopt in accrediting registrars and registries. Both are supported by the following international law enforcement agencies: • Australian Federal Police; • Department of Justice (US); • Federal Bureau of Investigation (US); • New Zealand Police; • Royal Canadian Mounted Police; • Serious Organised Crime Agency (UK) The amendments are considered to be required in order to aid the prevention and disruption of efforts to exploit domain registration procedures by Criminal Groups for criminal purposes. The proposed amendments take account of existing EU, US, Canadian and Australian legislation and those countries commitment to preserving individual’s rights to privacy. These amendments would maintain these protections whilst facilitating effective investigation of Internet related crime. I. Proposed Amendments to the RAA (May 21, 2009 version) ======================================================== 1) The RAA should not explicitly condone or encourage the use of Proxy Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN signed with the United States Department of Commerce on September 25, 2006 which specifically states “ICANN shall continue to enforce existing (Whois) policy”, i.e., totally open and public WHOIS, and the September 30, 2009, Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information.” Lastly, proxy and privacy registrations contravene the 2007 GAC Principles on WHOIS. If there are proxy and/or privacy domain name registrations, the following is recommended concerning their use: a. Registrars are to accept proxy/privacy registrations only from ICANN accredited Proxy Registration Services;1 (1: ICANN to implement accreditation system for Proxy Services using the same stringent checks and assurances as provided in these points, to ensure that all proxy services used are traceable and can supply correct details of registrant to relevant authorities.) b. Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity. 2) To RAA paragraph 5.3.2.1, language should be added to the effect “or knowingly and/or through gross negligence permit criminal activity in the registration of domain names or provision of domain name WHOIS information…” 3) All Accredited Registrars must submit to ICANN accurate and verifiable contact details of their main operational and physical office location, including country, phone number (with international prefix), street address, city, and region, to be publicly disclosed in ICANN web directory. Address must also be posted clearly on the Registrar's main website. Post Office boxes, incorporation addresses, mail-drop, and mail-forwarding locations will not be acceptable. In addition, Registrar must submit URL and location of Port 43 WHOIS server. 4) Registrars must publicly display of the name of CEO, President, and/or other responsible officer(s). 5) Registrars with multiple accreditations must disclose and publicly display on their website parent ownership or corporate relationship, i.e., identify controlling interests. 6) Registrar must notify ICANN immediately of the following and concurrently update Registrar website: a. any and all changes to a Registrar’s location; b. changes to presiding officer(s); c. bankruptcy filing; d. change of ownership; e. criminal convictions ; f. legal/civil actions 7) Registrar should be legal entity within the country of operation, and should provide ICANN with official certification of business registration or license. 8) Resellers must be held completely accountable to ALL provisions of the RAA. Registrars must contractually obligate all its Resellers to comply and enforce all RAA provisions. The Registrar will be held directly liable for any breach of the RAA a Reseller commits in which the Registrar does not remediate immediately. All Registrar resellers and third-party beneficiaries should be listed and reported to ICANN who shall maintain accurate and updated records. 9) Registrars and all associated third-party beneficiaries to Registrars are required to collect and securely maintain the following data (Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (i) Source IP address (ii) HTTP Request Headers (a) From (b) Accept (c) Accept‐Encoding (d) Accept‐Language (e) User‐Agent (f) Referrer (g) Authorization (h) Charge‐To (i) If‐Modified‐Since (iii) Collect and store the following data from registrants: (a) First Name: (b) Last Name: (c) E‐mail Address: (d) Alternate E‐mail address (e) Company Name: (f) Position: (g) Address 1: (h) Address 2: (i) City: (j) Country: (k) State: (l) Enter State: (m) Zip: (n) Phone Number: (o) Additional Phone: (p) Fax: (q) Alternative Contact First Name: (r) Alternative Contact Last Name: (s) Alternative Contact E‐mail: (t) Alternative Contact Phone: (iv) Collect data on all additional add‐on services purchased during the registration process. (v) All financial transactions, including, but not limited to credit card, payment information. 10) Each registrar is required to validate the following data upon receipt from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (1) Technical Data (a) IP addresses used to register domain names. (b) E‐mail Address (i) Verify that registration e‐mail address(es) are valid. (2) Billing Data (a) Validate billing data based on the payment card industry (PCI standards), at a minimum, the latest version of the PCI Data Security Standard (DSS). (3) Contact Data (a) Validate data is being provided by a human by using some anti‐automatic form submission technology (such as dynamic imaging) to ensure registrations are done by humans. (b) Validate current address WHOIS data and correlate with in‐house fraudulent data for domain contact information and registrant’s IP address. (4) Phone Numbers (i) Confirm that point of contact phone numbers are valid using an automated system. (ii) Cross validate the phone number area code with the provided address and credit card billing address. 11) Registrar must provide abuse contact information, including the SSAC SAC 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of Contact, 25 February 2009): • Registrars must prominently publish abuse contact information on their website and WHOIS. 1. The registrar identified in the sponsoring registrar field of a Whois entry should have an abuse contact listed prominently on its web page. To assist the community in locating this page, registrars should use uniform naming convention to facilitate (automated and rapid) discovery of this page, i.e., http://www.<registar>.<TLD>/abuse.html. 2. Registrars should provide ICANN with their abuse contact information and ICANN should publish this information at http://www.internic.net/regist.html. • The information a registrar publishes for the abuse point of contact should be consistent with contact details currently proposed as an amendment to Section 3.16 of the RAA. Each contact method (telephone, email, postal address) should reach an individual at the Registrar who will be able to promptly and competently attend to an abuse claim; for example, no contact should intentionally reject postal or email submissions. • Registrars should provide complainants with a well-defined, auditable way to track abuse complaints (e.g. a ticketing or similar tracking system). 12) ICANN should require Registrars to have a Service Level Agreement for their Port 43 servers. II. Proposed ICANN Due Diligence on current and new gTLD Registrars and Registries ================================================================================== a. ICANN to conduct enhanced due diligence on all Registrars and Registries (including but not limited to owners, officers, board of directors) ICANN accredits, or has accredited, to include, but not limited to: • criminal checks; • credit checks; • financial history and solvency; • corporate/company structure and ownership. For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc. b. Such due diligence shall be documented by ICANN, in detail, in a written report that can be provided upon request to appropriate auditors. c. ICANN should provide complainants with well-defined and auditable way to track complaints against Registrars and Registries. i. ICANN should publish annual detailed reports of reported complaints. d. ICANN should conduct WHOIS compliance audits, at least once a year, and publish results on: i. Port 43 ii. WHOIS accuracy
Kristina & Bruce, As part of the work of the GNSO's RAA Drafting Team, law enforcement representatives participated in the group's meeting in Seoul and in one of their bi-weekly meetings to share their perspective and their proposed amendments. The RAA working group is currently evaluating these and other RAA amendment proposals for inclusion into its report to the GNSO Council that is expected to be delivered before Brussels. If you would like more information on the LE proposals, please see: Seoul Meeting: http://sel.icann.org/node/7372 RAA Working Group email with the LE proposals attached: http://forum.icann.org/lists/gnso-raa-b/msg00010.html LE Discussion with the RAA drafting team: Transcript of RAA meeting on 3 December 2009, where law enforcement representative Bobby Flaim discussed these proposals: http://gnso.icann.org/meetings/transcript-raa-sub-team-b-03dec09-en.pdf Best Regards, Margie _______________ Margie Milam Senior Policy Counselor ICANN _______________ -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Rosette, Kristina Sent: Tuesday, April 13, 2010 7:42 AM To: Bruce Tonkin; GNSO Council Subject: RE: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Thanks, Bruce. They were originally proposed at one of the Monday afternoon malicious conduct sessions during the Seoul meeting. The meeting "node" doesn't have the presentation, which I recall was somewhat broader (albeit less specific) than below. If anyone can point me in the right direction, I'd appreciate it. -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bruce Tonkin Sent: Tuesday, April 13, 2010 1:14 AM To: GNSO Council Subject: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Not sure where the original law enforcement document was submitted. Below is what I found at: https://st.icann.org/raa-related/index.cgi/LawEnforcementRAArecommendations%.... Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Introduction: Below are: 1) suggested amendments to the RAA and; 2) due diligence recommendations for ICANN to adopt in accrediting registrars and registries. Both are supported by the following international law enforcement agencies: • Australian Federal Police; • Department of Justice (US); • Federal Bureau of Investigation (US); • New Zealand Police; • Royal Canadian Mounted Police; • Serious Organised Crime Agency (UK) The amendments are considered to be required in order to aid the prevention and disruption of efforts to exploit domain registration procedures by Criminal Groups for criminal purposes. The proposed amendments take account of existing EU, US, Canadian and Australian legislation and those countries commitment to preserving individual’s rights to privacy. These amendments would maintain these protections whilst facilitating effective investigation of Internet related crime. I. Proposed Amendments to the RAA (May 21, 2009 version) ======================================================== 1) The RAA should not explicitly condone or encourage the use of Proxy Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN signed with the United States Department of Commerce on September 25, 2006 which specifically states “ICANN shall continue to enforce existing (Whois) policy”, i.e., totally open and public WHOIS, and the September 30, 2009, Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information.” Lastly, proxy and privacy registrations contravene the 2007 GAC Principles on WHOIS. If there are proxy and/or privacy domain name registrations, the following is recommended concerning their use: a. Registrars are to accept proxy/privacy registrations only from ICANN accredited Proxy Registration Services;1 (1: ICANN to implement accreditation system for Proxy Services using the same stringent checks and assurances as provided in these points, to ensure that all proxy services used are traceable and can supply correct details of registrant to relevant authorities.) b. Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity. 2) To RAA paragraph 5.3.2.1, language should be added to the effect “or knowingly and/or through gross negligence permit criminal activity in the registration of domain names or provision of domain name WHOIS information…” 3) All Accredited Registrars must submit to ICANN accurate and verifiable contact details of their main operational and physical office location, including country, phone number (with international prefix), street address, city, and region, to be publicly disclosed in ICANN web directory. Address must also be posted clearly on the Registrar's main website. Post Office boxes, incorporation addresses, mail-drop, and mail-forwarding locations will not be acceptable. In addition, Registrar must submit URL and location of Port 43 WHOIS server. 4) Registrars must publicly display of the name of CEO, President, and/or other responsible officer(s). 5) Registrars with multiple accreditations must disclose and publicly display on their website parent ownership or corporate relationship, i.e., identify controlling interests. 6) Registrar must notify ICANN immediately of the following and concurrently update Registrar website: a. any and all changes to a Registrar’s location; b. changes to presiding officer(s); c. bankruptcy filing; d. change of ownership; e. criminal convictions ; f. legal/civil actions 7) Registrar should be legal entity within the country of operation, and should provide ICANN with official certification of business registration or license. 8) Resellers must be held completely accountable to ALL provisions of the RAA. Registrars must contractually obligate all its Resellers to comply and enforce all RAA provisions. The Registrar will be held directly liable for any breach of the RAA a Reseller commits in which the Registrar does not remediate immediately. All Registrar resellers and third-party beneficiaries should be listed and reported to ICANN who shall maintain accurate and updated records. 9) Registrars and all associated third-party beneficiaries to Registrars are required to collect and securely maintain the following data (Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (i) Source IP address (ii) HTTP Request Headers (a) From (b) Accept (c) Accept‐Encoding (d) Accept‐Language (e) User‐Agent (f) Referrer (g) Authorization (h) Charge‐To (i) If‐Modified‐Since (iii) Collect and store the following data from registrants: (a) First Name: (b) Last Name: (c) E‐mail Address: (d) Alternate E‐mail address (e) Company Name: (f) Position: (g) Address 1: (h) Address 2: (i) City: (j) Country: (k) State: (l) Enter State: (m) Zip: (n) Phone Number: (o) Additional Phone: (p) Fax: (q) Alternative Contact First Name: (r) Alternative Contact Last Name: (s) Alternative Contact E‐mail: (t) Alternative Contact Phone: (iv) Collect data on all additional add‐on services purchased during the registration process. (v) All financial transactions, including, but not limited to credit card, payment information. 10) Each registrar is required to validate the following data upon receipt from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (1) Technical Data (a) IP addresses used to register domain names. (b) E‐mail Address (i) Verify that registration e‐mail address(es) are valid. (2) Billing Data (a) Validate billing data based on the payment card industry (PCI standards), at a minimum, the latest version of the PCI Data Security Standard (DSS). (3) Contact Data (a) Validate data is being provided by a human by using some anti‐automatic form submission technology (such as dynamic imaging) to ensure registrations are done by humans. (b) Validate current address WHOIS data and correlate with in‐house fraudulent data for domain contact information and registrant’s IP address. (4) Phone Numbers (i) Confirm that point of contact phone numbers are valid using an automated system. (ii) Cross validate the phone number area code with the provided address and credit card billing address. 11) Registrar must provide abuse contact information, including the SSAC SAC 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of Contact, 25 February 2009): • Registrars must prominently publish abuse contact information on their website and WHOIS. 1. The registrar identified in the sponsoring registrar field of a Whois entry should have an abuse contact listed prominently on its web page. To assist the community in locating this page, registrars should use uniform naming convention to facilitate (automated and rapid) discovery of this page, i.e., http://www.<registar>.<TLD>/abuse.html. 2. Registrars should provide ICANN with their abuse contact information and ICANN should publish this information at http://www.internic.net/regist.html. • The information a registrar publishes for the abuse point of contact should be consistent with contact details currently proposed as an amendment to Section 3.16 of the RAA. Each contact method (telephone, email, postal address) should reach an individual at the Registrar who will be able to promptly and competently attend to an abuse claim; for example, no contact should intentionally reject postal or email submissions. • Registrars should provide complainants with a well-defined, auditable way to track abuse complaints (e.g. a ticketing or similar tracking system). 12) ICANN should require Registrars to have a Service Level Agreement for their Port 43 servers. II. Proposed ICANN Due Diligence on current and new gTLD Registrars and Registries ================================================================================== a. ICANN to conduct enhanced due diligence on all Registrars and Registries (including but not limited to owners, officers, board of directors) ICANN accredits, or has accredited, to include, but not limited to: • criminal checks; • credit checks; • financial history and solvency; • corporate/company structure and ownership. For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc. b. Such due diligence shall be documented by ICANN, in detail, in a written report that can be provided upon request to appropriate auditors. c. ICANN should provide complainants with well-defined and auditable way to track complaints against Registrars and Registries. i. ICANN should publish annual detailed reports of reported complaints. d. ICANN should conduct WHOIS compliance audits, at least once a year, and publish results on: i. Port 43 ii. WHOIS accuracy
Note that I forwarded this to Janis as follow-up to his letter to the Board and request that the GNSO RAA WG consider this. Chuck
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Margie Milam Sent: Tuesday, April 13, 2010 1:20 PM To: Rosette, Kristina; Bruce Tonkin; GNSO Council Subject: RE: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence
Kristina & Bruce,
As part of the work of the GNSO's RAA Drafting Team, law enforcement representatives participated in the group's meeting in Seoul and in one of their bi-weekly meetings to share their perspective and their proposed amendments. The RAA working group is currently evaluating these and other RAA amendment proposals for inclusion into its report to the GNSO Council that is expected to be delivered before Brussels.
If you would like more information on the LE proposals, please see:
Seoul Meeting: http://sel.icann.org/node/7372
RAA Working Group email with the LE proposals attached:
http://forum.icann.org/lists/gnso-raa-b/msg00010.html
LE Discussion with the RAA drafting team:
Transcript of RAA meeting on 3 December 2009, where law enforcement representative Bobby Flaim discussed these proposals: http://gnso.icann.org/meetings/transcript-raa-sub-team-b-03dec 09-en.pdf
Best Regards,
Margie
_______________ Margie Milam Senior Policy Counselor ICANN _______________
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Rosette, Kristina Sent: Tuesday, April 13, 2010 7:42 AM To: Bruce Tonkin; GNSO Council Subject: RE: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence
Thanks, Bruce.
They were originally proposed at one of the Monday afternoon malicious conduct sessions during the Seoul meeting. The meeting "node" doesn't have the presentation, which I recall was somewhat broader (albeit less specific) than below. If anyone can point me in the right direction, I'd appreciate it.
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bruce Tonkin Sent: Tuesday, April 13, 2010 1:14 AM To: GNSO Council Subject: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence
Not sure where the original law enforcement document was submitted. Below is what I found at:
https://st.icann.org/raa-related/index.cgi/LawEnforcementRAAre commendations%20(2).doc?action=attachments_download;page_name= 05_january_2010;id=20091118185109-0-21002.
Law Enforcement Recommend RAA Amendments and ICANN Due Diligence
Introduction: Below are: 1) suggested amendments to the RAA and; 2) due diligence recommendations for ICANN to adopt in accrediting registrars and registries. Both are supported by the following international law enforcement agencies:
• Australian Federal Police; • Department of Justice (US); • Federal Bureau of Investigation (US); • New Zealand Police; • Royal Canadian Mounted Police; • Serious Organised Crime Agency (UK)
The amendments are considered to be required in order to aid the prevention and disruption of efforts to exploit domain registration procedures by Criminal Groups for criminal purposes. The proposed amendments take account of existing EU, US, Canadian and Australian legislation and those countries commitment to preserving individual’s rights to privacy. These amendments would maintain these protections whilst facilitating effective investigation of Internet related crime.
I. Proposed Amendments to the RAA (May 21, 2009 version) ========================================================
1) The RAA should not explicitly condone or encourage the use of Proxy Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN signed with the United States Department of Commerce on September 25, 2006 which specifically states “ICANN shall continue to enforce existing (Whois) policy”, i.e., totally open and public WHOIS, and the September 30, 2009, Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information.” Lastly, proxy and privacy registrations contravene the 2007 GAC Principles on WHOIS.
If there are proxy and/or privacy domain name registrations, the following is recommended concerning their use:
a. Registrars are to accept proxy/privacy registrations only from ICANN accredited Proxy Registration Services;1
(1: ICANN to implement accreditation system for Proxy Services using the same stringent checks and assurances as provided in these points, to ensure that all proxy services used are traceable and can supply correct details of registrant to relevant authorities.)
b. Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity.
2) To RAA paragraph 5.3.2.1, language should be added to the effect “or knowingly and/or through gross negligence permit criminal activity in the registration of domain names or provision of domain name WHOIS information…”
3) All Accredited Registrars must submit to ICANN accurate and verifiable contact details of their main operational and physical office location, including country, phone number (with international prefix), street address, city, and region, to be publicly disclosed in ICANN web directory. Address must also be posted clearly on the Registrar's main website. Post Office boxes, incorporation addresses, mail-drop, and mail-forwarding locations will not be acceptable. In addition, Registrar must submit URL and location of Port 43 WHOIS server.
4) Registrars must publicly display of the name of CEO, President, and/or other responsible officer(s).
5) Registrars with multiple accreditations must disclose and publicly display on their website parent ownership or corporate relationship, i.e., identify controlling interests.
6) Registrar must notify ICANN immediately of the following and concurrently update Registrar website:
a. any and all changes to a Registrar’s location; b. changes to presiding officer(s); c. bankruptcy filing; d. change of ownership; e. criminal convictions ; f. legal/civil actions
7) Registrar should be legal entity within the country of operation, and should provide ICANN with official certification of business registration or license.
8) Resellers must be held completely accountable to ALL provisions of the RAA. Registrars must contractually obligate all its Resellers to comply and enforce all RAA provisions. The Registrar will be held directly liable for any breach of the RAA a Reseller commits in which the Registrar does not remediate immediately. All Registrar resellers and third-party beneficiaries should be listed and reported to ICANN who shall maintain accurate and updated records.
9) Registrars and all associated third-party beneficiaries to Registrars are required to collect and securely maintain the following data (Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008):
(i) Source IP address
(ii) HTTP Request Headers
(a) From (b) Accept (c) Accept‐Encoding (d) Accept‐Language (e) User‐Agent (f) Referrer (g) Authorization (h) Charge‐To (i) If‐Modified‐Since
(iii) Collect and store the following data from registrants:
(a) First Name: (b) Last Name: (c) E‐mail Address: (d) Alternate E‐mail address (e) Company Name: (f) Position: (g) Address 1: (h) Address 2: (i) City: (j) Country: (k) State: (l) Enter State: (m) Zip: (n) Phone Number: (o) Additional Phone: (p) Fax: (q) Alternative Contact First Name: (r) Alternative Contact Last Name: (s) Alternative Contact E‐mail: (t) Alternative Contact Phone:
(iv) Collect data on all additional add‐on services purchased during the registration process.
(v) All financial transactions, including, but not limited to credit card, payment information.
10) Each registrar is required to validate the following data upon receipt from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008):
(1) Technical Data
(a) IP addresses used to register domain names.
(b) E‐mail Address
(i) Verify that registration e‐mail address(es) are valid.
(2) Billing Data
(a) Validate billing data based on the payment card industry (PCI standards), at a minimum, the latest version of the PCI Data Security Standard (DSS).
(3) Contact Data
(a) Validate data is being provided by a human by using some anti‐automatic form submission technology (such as dynamic imaging) to ensure registrations are done by humans.
(b) Validate current address WHOIS data and correlate with in‐house fraudulent data for domain contact information and registrant’s IP address.
(4) Phone Numbers
(i) Confirm that point of contact phone numbers are valid using an automated system.
(ii) Cross validate the phone number area code with the provided address and credit card billing address.
11) Registrar must provide abuse contact information, including the SSAC SAC 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of Contact, 25 February 2009):
• Registrars must prominently publish abuse contact information on their website and WHOIS.
1. The registrar identified in the sponsoring registrar field of a Whois entry should have an abuse contact listed prominently on its web page. To assist the community in locating this page, registrars should use uniform naming convention to facilitate (automated and rapid) discovery of this page, i.e., http://www.<registar>.<TLD>/abuse.html.
2. Registrars should provide ICANN with their abuse contact information and ICANN should publish this information at http://www.internic.net/regist.html.
• The information a registrar publishes for the abuse point of contact should be consistent with contact details currently proposed as an amendment to Section 3.16 of the RAA. Each contact method (telephone, email, postal address) should reach an individual at the Registrar who will be able to promptly and competently attend to an abuse claim; for example, no contact should intentionally reject postal or email submissions.
• Registrars should provide complainants with a well-defined, auditable way to track abuse complaints (e.g. a ticketing or similar tracking system).
12) ICANN should require Registrars to have a Service Level Agreement for their Port 43 servers.
II. Proposed ICANN Due Diligence on current and new gTLD Registrars and Registries ============================================================== ====================
a. ICANN to conduct enhanced due diligence on all Registrars and Registries (including but not limited to owners, officers, board of directors) ICANN accredits, or has accredited, to include, but not limited to:
• criminal checks; • credit checks; • financial history and solvency; • corporate/company structure and ownership.
For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc.
b. Such due diligence shall be documented by ICANN, in detail, in a written report that can be provided upon request to appropriate auditors.
c. ICANN should provide complainants with well-defined and auditable way to track complaints against Registrars and Registries.
i. ICANN should publish annual detailed reports of reported complaints.
d. ICANN should conduct WHOIS compliance audits, at least once a year, and publish results on:
i. Port 43
ii. WHOIS accuracy
Thanks Bruce, the RAA-WG is examining some of these recommendations, the RAP-WG is examining a couple of them, but much of it involves WHOIS. Of course the policy development around that has stagnated as we need to approve the studies that have been anticipated for well over a year now. Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1 (415) 738-8087 http://rodenbaugh.com -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bruce Tonkin Sent: Monday, April 12, 2010 10:14 PM To: GNSO Council Subject: [council] Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Not sure where the original law enforcement document was submitted. Below is what I found at: https://st.icann.org/raa-related/index.cgi/LawEnforcementRAArecommendations%.... Law Enforcement Recommend RAA Amendments and ICANN Due Diligence Introduction: Below are: 1) suggested amendments to the RAA and; 2) due diligence recommendations for ICANN to adopt in accrediting registrars and registries. Both are supported by the following international law enforcement agencies: • Australian Federal Police; • Department of Justice (US); • Federal Bureau of Investigation (US); • New Zealand Police; • Royal Canadian Mounted Police; • Serious Organised Crime Agency (UK) The amendments are considered to be required in order to aid the prevention and disruption of efforts to exploit domain registration procedures by Criminal Groups for criminal purposes. The proposed amendments take account of existing EU, US, Canadian and Australian legislation and those countries commitment to preserving individual’s rights to privacy. These amendments would maintain these protections whilst facilitating effective investigation of Internet related crime. I. Proposed Amendments to the RAA (May 21, 2009 version) ======================================================== 1) The RAA should not explicitly condone or encourage the use of Proxy Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN signed with the United States Department of Commerce on September 25, 2006 which specifically states “ICANN shall continue to enforce existing (Whois) policy”, i.e., totally open and public WHOIS, and the September 30, 2009, Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information.” Lastly, proxy and privacy registrations contravene the 2007 GAC Principles on WHOIS. If there are proxy and/or privacy domain name registrations, the following is recommended concerning their use: a. Registrars are to accept proxy/privacy registrations only from ICANN accredited Proxy Registration Services;1 (1: ICANN to implement accreditation system for Proxy Services using the same stringent checks and assurances as provided in these points, to ensure that all proxy services used are traceable and can supply correct details of registrant to relevant authorities.) b. Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity. 2) To RAA paragraph 5.3.2.1, language should be added to the effect “or knowingly and/or through gross negligence permit criminal activity in the registration of domain names or provision of domain name WHOIS information…” 3) All Accredited Registrars must submit to ICANN accurate and verifiable contact details of their main operational and physical office location, including country, phone number (with international prefix), street address, city, and region, to be publicly disclosed in ICANN web directory. Address must also be posted clearly on the Registrar's main website. Post Office boxes, incorporation addresses, mail-drop, and mail-forwarding locations will not be acceptable. In addition, Registrar must submit URL and location of Port 43 WHOIS server. 4) Registrars must publicly display of the name of CEO, President, and/or other responsible officer(s). 5) Registrars with multiple accreditations must disclose and publicly display on their website parent ownership or corporate relationship, i.e., identify controlling interests. 6) Registrar must notify ICANN immediately of the following and concurrently update Registrar website: a. any and all changes to a Registrar’s location; b. changes to presiding officer(s); c. bankruptcy filing; d. change of ownership; e. criminal convictions ; f. legal/civil actions 7) Registrar should be legal entity within the country of operation, and should provide ICANN with official certification of business registration or license. 8) Resellers must be held completely accountable to ALL provisions of the RAA. Registrars must contractually obligate all its Resellers to comply and enforce all RAA provisions. The Registrar will be held directly liable for any breach of the RAA a Reseller commits in which the Registrar does not remediate immediately. All Registrar resellers and third-party beneficiaries should be listed and reported to ICANN who shall maintain accurate and updated records. 9) Registrars and all associated third-party beneficiaries to Registrars are required to collect and securely maintain the following data (Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (i) Source IP address (ii) HTTP Request Headers (a) From (b) Accept (c) Accept‐Encoding (d) Accept‐Language (e) User‐Agent (f) Referrer (g) Authorization (h) Charge‐To (i) If‐Modified‐Since (iii) Collect and store the following data from registrants: (a) First Name: (b) Last Name: (c) E‐mail Address: (d) Alternate E‐mail address (e) Company Name: (f) Position: (g) Address 1: (h) Address 2: (i) City: (j) Country: (k) State: (l) Enter State: (m) Zip: (n) Phone Number: (o) Additional Phone: (p) Fax: (q) Alternative Contact First Name: (r) Alternative Contact Last Name: (s) Alternative Contact E‐mail: (t) Alternative Contact Phone: (iv) Collect data on all additional add‐on services purchased during the registration process. (v) All financial transactions, including, but not limited to credit card, payment information. 10) Each registrar is required to validate the following data upon receipt from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices Recommendations for Registrars”, October 2008): (1) Technical Data (a) IP addresses used to register domain names. (b) E‐mail Address (i) Verify that registration e‐mail address(es) are valid. (2) Billing Data (a) Validate billing data based on the payment card industry (PCI standards), at a minimum, the latest version of the PCI Data Security Standard (DSS). (3) Contact Data (a) Validate data is being provided by a human by using some anti‐automatic form submission technology (such as dynamic imaging) to ensure registrations are done by humans. (b) Validate current address WHOIS data and correlate with in‐house fraudulent data for domain contact information and registrant’s IP address. (4) Phone Numbers (i) Confirm that point of contact phone numbers are valid using an automated system. (ii) Cross validate the phone number area code with the provided address and credit card billing address. 11) Registrar must provide abuse contact information, including the SSAC SAC 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of Contact, 25 February 2009): • Registrars must prominently publish abuse contact information on their website and WHOIS. 1. The registrar identified in the sponsoring registrar field of a Whois entry should have an abuse contact listed prominently on its web page. To assist the community in locating this page, registrars should use uniform naming convention to facilitate (automated and rapid) discovery of this page, i.e., http://www.<registar>.<TLD>/abuse.html. 2. Registrars should provide ICANN with their abuse contact information and ICANN should publish this information at http://www.internic.net/regist.html. • The information a registrar publishes for the abuse point of contact should be consistent with contact details currently proposed as an amendment to Section 3.16 of the RAA. Each contact method (telephone, email, postal address) should reach an individual at the Registrar who will be able to promptly and competently attend to an abuse claim; for example, no contact should intentionally reject postal or email submissions. • Registrars should provide complainants with a well-defined, auditable way to track abuse complaints (e.g. a ticketing or similar tracking system). 12) ICANN should require Registrars to have a Service Level Agreement for their Port 43 servers. II. Proposed ICANN Due Diligence on current and new gTLD Registrars and Registries ================================================================================== a. ICANN to conduct enhanced due diligence on all Registrars and Registries (including but not limited to owners, officers, board of directors) ICANN accredits, or has accredited, to include, but not limited to: • criminal checks; • credit checks; • financial history and solvency; • corporate/company structure and ownership. For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc. b. Such due diligence shall be documented by ICANN, in detail, in a written report that can be provided upon request to appropriate auditors. c. ICANN should provide complainants with well-defined and auditable way to track complaints against Registrars and Registries. i. ICANN should publish annual detailed reports of reported complaints. d. ICANN should conduct WHOIS compliance audits, at least once a year, and publish results on: i. Port 43 ii. WHOIS accuracy
participants (5)
-
Bruce Tonkin -
Gomes, Chuck -
Margie Milam -
Mike Rodenbaugh -
Rosette, Kristina