- Bc-gnso - lists.icann.org

RE: [bc-gnso] Draft BC comment on Proposed New GNSO Policy Development Process
by john＠crediblecontext.com March 27, 2011

March 27, 2011

1 0

Bc Call reminder
by Benedetta Rossi March 26, 2011

March 26, 2011

Dear Members, Just a reminder of the gnso council prep call for BC members taking place on Thursday, 31st of March 2011 at 10am ET (15.00 UTC). Full agenda and dial in details to follow. Thank you, Kindest regards, Benedetta Rossi BC Secretariat

1 0

Business Constituency statement on the Board Reply to GAC Scorecard
by Steve DelBianco March 25, 2011

March 25, 2011

Attached is a written statement of the BC on the Board – GAC negotiations over the new gTLD Scorecard. This was provided to ICANN staff today, in time for their guidebook redline work. Kurt & Karen - As officers of the BC, Marilyn Cade and I prepared a written statement summarizing comments made by the BC last week in SFO regarding the GAC Scorecard. We understand this statement may be of help as you and the Board develop the Guidebook redline and response to the GAC Scorecard.

1 0

RE: [bc-gnso] Hackers exploit chink in Web's armor
by lynn＠goodsecurityconsulting.com March 25, 2011

March 25, 2011

2 1

Re: [bc-gnso] Proposed BC comment on ICANN proposed budget for 2012
by Chris Chaplow March 25, 2011

March 25, 2011

To Mikey, Thanks for the suggestion, I will incorporate into the document. To All members, In my submission is the list of ten projects that are published in the framework (total cost 11.1m$ or about 20%) Although some are obvious, there is no detail or references in the framework as to what exactly these project are. I want to order them in BC member priority, so have made a first attempt below. Any suggestions? . WHOIS Studies SLA Monitoring System Development DNSSEC Deployment and Training IANA Business Excellence Global DNS SSR Symposium Security Program Certifications Affirmation of Commitments reviews and Recommendations Implementation IDN Variant New gTLD project DNS Measurement & Metrics ---end--- Chris Chaplow Managing Director Andalucia Web Solutions Avenida del Carmen 9 Ed. Puertosol, Puerto Deportivo 1ª Planta, Oficina 30 Estepona, 29680 Malaga, Spain Tel: + (34) 952 897 865 Fax: + (34) 952 897 874 E-mail: <mailto:chris@andaluciaws.com> chris(a)andaluciaws.com Web: <http://www.andaluciaws.com/> www.andaluciaws.com

3 4

Hackers exploit chink in Web's armor
by Phil Corwin March 24, 2011

March 24, 2011

I'm not sure if there is a role for ICANN in addressing this, but it certainly appears to be a major Internet/e-commerce security issue --- http://news.cnet.com/8301-31921_3-20046588-281.html?tag=nl.e703 March 24, 2011 4:00 AM PDT Hackers exploit chink in Web's armor by Declan <http://www.cnet.com/profile/declan00/> McCullagh and Elinor<http://www.cnet.com/profile/elinormills/> Mills<http://www.cnet.com/profile/elinormills/> A long-known but little-discussed vulnerability in the modern Internet's design was highlighted yesterday by a report<http://news.cnet.com/8301-31921_3-20046340-281.html> that hackers traced to Iran spoofed the encryption procedures used to secure connections to Google, Yahoo, Microsoft, and other major Web sites. This design, pioneered by Netscape in the early and mid-1990s, allows the creation of encrypted channels to Web sites, an important security feature typically identified by a closed lock icon in a browser. The system relies on third parties to issue so-called certificates that prove that a Web site is legitimate when making an "https://" connection. The problem, however, is that the list of certificate issuers has ballooned over the years to approximately 650 organizations, which may not always follow the strictest security procedures. And each one has a copy of the Web's master keys. [Compromise related to fraudulent digital certificates is traced to IP addresses in Iran, Comodo says.] <http://i.i.com.com/cnwk.1d/i/tim/2011/03/23/ComodoIran.png> Compromise related to fraudulent digital certificates is traced to IP addresses in Iran, Comodo says. (Credit: Comodo<http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html>) "There is this problem that exists today where there are a very large number of certificate authorities that are trusted by everyone and everything," says Peter Eckersley<https://www.eff.org/about/staff/peter-eckersley>, senior staff technologist at the Electronic Frontier Foundation<http://www.eff.org/> who has compiled a list of them. This has resulted in a bizarre situation in which companies like Etisalat, a wireless carrier in the United Arab Emirates that implanted spyware<http://news.bbc.co.uk/2/hi/technology/8161190.stm> on customers' BlackBerry devices, possess the master keys that can be used to impersonate any Web site on the Internet, even the U.S. Treasury, BankofAmerica.com, and Google.com. So do more than 100 German universities, the U.S. Department of Homeland Security, and random organizations like the Gemini Observatory, which operates a pair of 8.1-meter diameter telescopes in Hawaii and Chile. It's a situation that nobody would have anticipated nearly two decades ago when the cryptographic protection known as SSL (Secure Sockets Layer) began to be embedded into Web browsers. At the time, the focus was on securing the connections, not on securing the certificate authorities themselves--or limiting their numbers. "It was the '90s," says security researcher Dan <http://dankaminsky.com/> Kaminsky, who discovered<http://news.cnet.com/8301-10789_3-9985618-57.html> a serious Domain Name System flaw in 2008. "We didn't realize how this system would grow." Today, there are now about 1,500 master keys, or signing certificates, trusted by Internet Explorer and Firefox<http://www.cnet.com/firefox-3/>. The vulnerability of today's authentication infrastructure came to light after Comodo, a Jersey City, N.J.-based firm that issues SSL certificates, alerted Web browser makers that an unnamed European partner had its systems compromised. The attack originated from an Iranian Internet Protocol address, according to Comodo Chief Executive Melih Abdulhayoglu, who told CNET that the skill and sophistication suggested a government was behind the intrusion. Spoofing those Web sites would allow the Iranian government to use what's known as a man-in-the-middle attack to impersonate the legitimate sites and grab passwords, read e-mail messages, and monitor any other activities its citizens performed, even if Web browsers show that the connections were securely protected with SSL encryption. If Comodo is correct about the attack originating from Iran, it wouldn't be the first government in the region to have taken similar steps. Late last year, the Tunisian government undertook<http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-h…> an ambitious scheme to steal an entire country's worth of Gmail, Yahoo, and Facebook passwords. It used malicious JavaScript code to siphon off unencrypted log-in credentials, which allowed government agents to infiltrate or delete protest-related discussions. Comodo's revelation throws into sharp relief the list of flaws inherent in the current system. There is no automated process to revoke fraudulent certificates. There is no public list of certificates that companies like Comodo have issued, or even which of its resellers or partners have been given a duplicate set of the master keys. There are no mechanisms to prevent fraudulent certificates for Yahoo Mail or Gmail from being issued by compromised companies, or repressive regimes bent on surveillance; Tunisia even has its own certificate-issuing government agency<http://www.certification.tn/index.php?id=4>. "These organizations act as cornerstones of security and trust on the Internet, but it seems like they're not doing basic due diligence that other organizations are expect to do, like the banks," says Mike Zusman, managing consultant at Web app security firm Intrepidus<http://intrepidusgroup.com/> Group<http://intrepidusgroup.com/>. "I'm not sure what we need to do but I think it's time we start addressing the issue of trust and issues of certificate authorities potentially not living up to standards that they should be." Over the last few years, a handful of papers and demonstrations at hacker conferences have focused more attention on the topic. But the Comodo intrusion, which appears to be the first public evidence of an actual attack on the way the Web handles authentication, could be a catalyst for rethinking the way to handle security. Two years ago, for instance, Zusman was able to get a certificate<http://intrepidusgroup.com/insight/2009/01/nobody-is-perfect/> from Thawte, a VeriSign subsidiary, for "login.live.com" just based on an e-mail address he created on the Hotmail domain. Even though it was revoked, it still worked in a Web browser during a demonstration at the Black Hat conference in Las Vegas. Comodo, too, has previously been shown to have lax security standards<https://blog.startcom.org/?p=145> among its resellers as far back as December 2008. "Remember, the only reason Iran has to go to the lengths they've gone to to get certificates is because they don't have a (certificate issuer) of their own... most countries can just generate their own," says Moxie Marlinspike, chief technology officer of mobile app developer Whisper Systems<http://www.whispersys.com/>, who has discovered serious problems<http://news.cnet.com/8301-27080_3-10299459-245.html> with Web authentication before. One problem, he says, is that companies that issue certificates have a strong economic incentive to make it as easy as possible to obtain them. Another worrisome aspect is that browser makers don't always have a good way to revoke fraudulent certificates. A discussion thread<https://bugzilla.mozilla.org/show_bug.cgi?id=642395> at Mozilla.org, makers of the Firefox browser, shows that after being alerted by Comodo, they had no process to revoke the faux certificates. Mozilla developers ended up having to write new code and test a patch, which took a few days and, even after its release, meant that only users who downloaded new versions of Firefox benefit. Google's Chrome, on the other hand, uses a transparent update system<http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-up…> for desktop versions but not necessarily mobile ones. Microsoft said yesterday<http://www.microsoft.com/technet/security/advisory/2524375.mspx> that "an update is available for all supported versions of Windows to help address this issue." Ross Anderson<http://www.cl.cam.ac.uk/~rja14/>, professor of security engineering at the University of Cambridge's computer laboratory, offered an anecdote in this paper (PDF<http://spw.stca.herts.ac.uk/2.pdf>): "I asked a panelist from the Mozilla Foundation why, when I updated Firefox the previous day, it had put back a certificate I'd previously deleted, from an organisation associated with the Turkish military and intelligence services. The Firefox spokesman said that I couldn't remove certificates--I had to leave them in but edit them to remove their capabilities - while an outraged Turkish delegate claimed that the body in question was merely a 'research organisation.'" Jacob Appelbaum, a Tor Project developer who is a subject of a legal spat<http://news.cnet.com/8301-31921_3-20042277-281.html> with the Justice Department over his work with <http://news.cnet.com/8301-1009_3-20010866-83.html> WikiLeaks, says Mozilla should have warned of the vulnerability immediately and shipped Firefox 4 with a way to detect and revoke bad certificates turned on by default. (The technique is called Online Certificate Status Protocol<http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol>, or OSCP). "Mozilla's not taking their responsibility to the Internet seriously," said Appelbaum, who wrote an independent analysis<https://blog.torproject.org/blog/detecting-certificate-authority-compromise…> of the situation. "A Web browser isn't a toy. It's being used as a tool to overthrow governments...At the end of the day, they did not put their users first." Some long-term technical fixes have been proposed, with names like DANE<http://www.ietf.org/id/draft-ietf-dane-protocol-06.txt>, HASTLS<http://tools.ietf.org/html/draft-hoffman-server-has-tls-04>, CAA<http://tools.ietf.org/html/draft-hallambaker-donotissue-03> (Comodo's Philip Hallam-Baker is a co-author), and Monkeysphere<http://web.monkeysphere.info/>. The technology known as Domain Name System Security Extensions<http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions>, or DNSSEC, can help. The Electronic Frontier Foundation's Eckersley, who runs the groups SSL<https://www.eff.org/observatory> Observatory<https://www.eff.org/observatory> that tracks SSL certificates, hints that he'll soon offer another proposal about how to reinforce the Web's cryptographic architecture. "We do in fact need a way not to trust everyone," Eckersley says. "We have 1,500 master certificates for the Web running around. That's 1,500 places that could be hacked and all of a sudden you have to scramble to dream up a solution." Read more: http://news.cnet.com/8301-31921_3-20046588-281.html#ixzz1HYctsBUi Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/cell "Luck is the residue of design" -- Branch Rickey

1 0

RE: [bc-gnso] Slides Part 1
by john＠crediblecontext.com March 23, 2011

March 23, 2011

1 0

RE: [bc-gnso] Proposed BC comment on ICANN proposed budget for 2012
by john＠crediblecontext.com March 23, 2011

March 23, 2011

1 0

RE: [bc-gnso] Proposed BC comment on ICANN proposed budget for 2012
by john＠crediblecontext.com March 23, 2011

March 23, 2011

1 0

BC Meeting, March 15 2011 slides
by Benedetta Rossi March 22, 2011

March 22, 2011

Dear Members, Please find attached the slides for the BC meeting that took place in San Francisco on the 15th of March 2011. Kindest Regards, Benedetta Rossi BC Secretariat

2 2