ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>STEPHEN CROCKER: HELLO. WE'RE GOING TO TRY TO PICK UP THE PACE AND JUST MOVE RIGHT ALONG HERE.
THIS IS A SESSION ON DOMAIN NAME HIJACKING.
BRUCE TONKIN AND RAM MOHAN, WHO ARE OVER HERE, AND I WILL GIVE A PRELIMINARY REPORT AND A DISCUSSION FROM THE PERSPECTIVE OF THE SECURITY AND STABILITY ADVISORY COMMITTEE ON THE PANIX.COM HIJACKING AND A SOMEWHAT BROADER SET OF ISSUES RELATED TO THAT.
I'LL LEAD OFF AND THEN WE'LL HAND OFF AND WE'LL MOVE RIGHT ALONG HERE.
IN THE MIDDLE OF JANUARY, GOING INTO THE WEEKEND, PANIX.COM WAS HIJACKED AND WAS EFFECTIVELY OFF THE AIR THROUGHOUT THE WEEKEND.
IT TOOK VIGOROUS ACTION BEHIND THE SCENES WITH QUITE A NUMBER OF WELL-INTENTIONED AND ACTIVE PEOPLE PITCHING IN TO HELP OUT TO RESTORE THE DOMAIN.
THE GAINING REGISTRAR AND THE RESELLER WERE AT FAULT IN SOME OF THEIR PROCEDURES, AND ICANN WROTE A REPORT TO THAT EFFECT.
BRUCE TONKIN IS CTO OF MELBOURNE I.T. AND WAS IN THE UNCOMFORTABLE POSITION OF BEING IN THE MIDDLE OF IT BECAUSE THAT'S WHERE THE -- THAT MELBOURNE I.T. WAS THE GAINING REGISTRAR.
THERE ISN'T ANY REAL ARGUMENT ABOUT WHETHER THERE WERE SOME LAPSES IN CONTROL. YET AT THE SAME TIME, WE THINK THAT'S NOT THE WHOLE OF THE PICTURE. WE THINK THAT THERE IS A BROADER PERSPECTIVE. AND THAT'S OUR PURPOSE HERE, IS TO OPEN UP THAT PICTURE A LITTLE BIT.
LET ME EMPHASIZE THAT THIS IS A PRELIMINARY REPORT. WE HAVE A FAIR AMOUNT OF WORK TO DO TO DOCUMENT AND PROBE SOME OF THE ASPECTS BEFORE THIS IS COMPLETE.
SO THIS IS VERY MUCH IN THE SPIRIT OF SHARING A PERSPECTIVE, SOME PRELIMINARY TENTATIVE CONCLUSIONS, AND THEN, QUITE OBVIOUSLY, TO OPEN UP THE DISCUSSION AND TO INVITE RESPONSES.
PANIX.COM IS A SOMEWHAT SPECIAL -- HAS A SOMEWHAT SPECIAL HISTORY. IT IS ONE OF THE OLDEST, MAYBE THE OLDEST, ISP THAT IS STILL CONNECTED AND HAS A TREASURED REPUTATION. IT'S SORT OF CONSIDERED A DARLING IN THE INDUSTRY.
SO WHEN THEY WERE IN TROUBLE, THEY WERE ABLE TO REACH OUT AND GET HELP FROM PEOPLE WHO HAD BEEN IN THE INDUSTRY FOR QUITE A LONG TIME.
NOT EVERY COMPANY THAT MIGHT BE HIJACKED WOULD BE SO FORTUNATE.
SO IT GOT CONSIDERABLY MORE ATTENTION THAT IT MIGHT HAVE IF IT WERE JUST SOME OTHER KIND OF COMPANY.
THERE -- THE HIJACKING OF THEM WAS NOT A UNIQUE EVENT. THIS DOESN'T HAPPEN A HUGE AMOUNT OF TIME, BUT IT DOES HAPPEN, AND EACH OF THE HIJACKINGS IS NOT NECESSARILY THE SAME.
WITH FAR LESS PUBLICITY, THERE WAS A RATHER EGREGIOUS HIJACKING OF THE DOMAIN HZ.COM, HZ BEING THE ABBREVIATION FOR HERTZ. AND THE DOMAIN HOLDER HAD HELD THAT FOR A CONSIDERABLE PERIOD OF TIME, FOR A DOZEN YEARS, I THINK. AND OF COURSE WITH A TWO-LETTER CODE LIKE THAT, IT'S RATHER PRIME REAL ESTATE, IF YOU WILL.
IT TOOK VIGOROUS ACTION OF A DIFFERENT KIND TO RETURN THAT, SO THERE'S ROOM FOR IMPROVEMENT IN THE WHOLE SYSTEM, IS OUR PERSPECTIVE. WHAT WE'LL COVER HERE TODAY IS A DESCRIPTION OF THE HIJACKINGS AND A PERSPECTIVE ON HOW, AS BAD AS THEY WERE, THEY'RE NOT AS BAD AS THEY COULD HAVE BEEN; THAT IS, THE RESULTS COULD HAVE BEEN CONSIDERABLY WORSE. THEN WE'LL STEP BACK AND LOOK A LITTLE BIT AT THE TRANSFER PROCESS WHERE THERE IS OPPORTUNITY FOR ERROR OR MISCHIEF, A COMMENT ABOUT THE RECENT CHANGE IN TRANSFER POLICY AND HOW THAT HAS -- WHERE THAT PLAYS IN THIS. AND JUST TO ANTICIPATE, THIS IS NOT AT ALL A SUGGESTION THAT THE TRANSFER POLICY -- THE CHANGE IN TRANSFER POLICY HAS MADE THE PROBLEM WORSE; THAT, IN FACT, IT IS ESSENTIALLY INDEPENDENT OF THAT.
AND WE LOOK FOR PLACES WHERE THERE COULD BE POTENTIAL IMPROVEMENTS IN THE TRANSFER POLICY.
AN ENTIRELY DIFFERENT AREA IS HOW DO YOU GET HELP AFTER SOMETHING BAD HAS HAPPENED? WHAT KIND OF EMERGENCY RESPONSE MECHANISMS ARE THERE? AND THAT'S ANOTHER AREA WHERE THERE'S ROOM FOR SOME IMPROVEMENTS.
AND SO AT THE END OF THIS, WE'LL MAKE A HANDFUL OF TENTATIVE RECOMMENDATIONS. AND I SAY TENTATIVE BECAUSE WE REALLY DO WANT TO SUBJECT THIS TO A MUCH CLOSER AND DEEPER ANALYSIS.
SO THE SECURITY PROBLEM HERE IS UNAUTHORIZED DISCLOSURE, ALTERATION, INSERTION OR DESTRUCTION OF DOMAIN NAME DATA.
THE DISCLOSURE PART IS REALLY DISCLOSURE OF THE SENSITIVE PIECES, PASSWORDS OR OTHER ASPECTS THAT CAN THEN BE USED TO ALTER OR DESTROY OR DENY ACCESS TO A DOMAIN NAME. SO OUR PRIMARY FOCUS IS ON THE CONTROL AND PROPER USE OF DOMAIN NAME; NOT SO MUCH THE PRIVACY OF THE DOMAIN NAME ITSELF.
AND THE DATA IN THE DOMAIN NAME INCLUDES -- IN THE DOMAIN NAME RECORDS INCLUDES THE ADDRESS RECORDS, WE'LL CALL THE "A" RECORD, THE MAIL TRANSFER RECORD IN CASE THAT EXISTS, THE MX RECORDS, THE ADDRESS OF THE NAME SERVERS, AND THE INFORMATION, OF COURSE, ABOUT THE REGISTRANT, WHO THE HOLDER IS, AND WHAT THE CONTACT POINTS ARE.
AND A SOMEWHAT LESS THOUGHT ABOUT, BUT OBVIOUSLY VERY IMPORTANT ASPECT, IS WHO IS THE REGISTRAR ASSOCIATED WITH THAT DOMAIN NAME. AND HERE WE'RE TALKING PRINCIPALLY IN THE GTLD ARENA WHERE THE REGISTRARS ARE THE PATH FOR GETTING INFORMATION INTO THE REGISTRIES.
THE PANIX.COM INCIDENT WAS AN UNAUTHORIZED CHANGE TO THE DNS INFORMATION, INCLUDING THE ADDRESS RECORDS AND THE MAIL EXCHANGE RECORDS, AND THE NAME HOLDER INFORMATION. AND THE IMPACT WAS THAT E-MAIL AND WEB SITES SERVICES SIMPLY CEASED OPERATION. AND IN EFFECT, PUT THE COMPANY OUT OF BUSINESS AND ALL OF THEIR USERS. NOT 100 PERCENT BECAUSE THEY HAVE OTHER ASPECTS TO THEIR BUSINESS, BUT FROM THE PERSPECTIVE OF LOOKING AT ACCESS THROUGH THE PANIX.COM DOMAIN NAME, IT WAS ESSENTIALLY A TOTAL SHUTDOWN.
THIS WAS QUITE SUBSTANTIAL AND DRAMATIC. THIS IS NOT A DISPUTE ABOUT $6 OR $30 OR ABOUT HOW LONG IT TAKES TO TRANSFER A DOMAIN NAME. THIS IS A CATACLYSMIC EVENT FOR THAT PARTICULAR COMPANY.
SO WHAT'S THE ROOT CAUSE? HOW COULD SUCH A THING HAPPEN?
AS WE'LL SEE IN DIGGING IN A LITTLE BIT, THERE WAS A FAILURE TO AUTHENTICATE THE REGISTRANT BY THE GAINING REGISTRAR; THAT IS, SOMEBODY PASSED THEMSELVES OFF AS THE ACTUAL REGISTRANT. BUT THEY DID SO FICTITIOUSLY. AND HE DID SO TO A -- TO A NEW REGISTRAR, NOT THE ONE THAT WAS IN PLACE THAT HAD THE RELATIONSHIP WITH PANIX.COM. THEY WENT TO A NEW REGISTRAR AND SAID, "I WOULD LIKE TO CHANGE MY REGISTRATION OVER TO YOU." AND THE NEW REGISTRAR SAYS, "GREAT; ALWAYS HAPPY TO HAVE NEW BUSINESS."
BUT THE NEW REGISTRAR IS SUPPOSED TO MAKE SURE THAT THEY REALLY ARE DEALING WITH THE LEGITIMATE REGISTRANT. AND THEY DIDN'T DO THE AUTHENTICATION PROCESS AS TIGHTLY AND AS STRONGLY AS THEY SHOULD HAVE.
ONCE THE DOMAIN NAME WAS TRANSFERRED, THE REGISTRANT INFORMATION WAS CHANGED AT THE NEW REGISTRAR, THE DNS NAME SERVER WAS CHANGED, AND ALL OF THE ADDRESSES WERE CHANGED.
AND AT THAT POINT, TRAFFIC THAT HAD BEEN HANDED TO THE REAL PANIX.COM SITES WENT ELSEWHERE.
LET ME BACK UP.
IN PARALLEL BUT WITH A GREAT DEAL LESS VISIBILITY, THERE WAS A HIJACKING OF THE DOMAIN HERTZ.COM, HZ.COM.
AND THIS WAS NOT A DOMAIN THAT WAS IN THE SAME LEVEL OF USE. AND IT WAS NOT NOTICED RIGHT AWAY.
IT WAS CAUGHT BY A RANDOM WHOIS CHECK.
AND IN THIS CASE, THERE WAS A MUCH DEEPER PENETRATION OF THE FACILITIES SO THAT THE TRANSFER WAS INITIATED AS IF IT LOOKED LIKE A LEGITIMATE TRANSFER, AND THE FACILITIES OF THE LOSING REGISTRAR WERE COMPROMISED SO THAT WHEN THE CHECK CAME BACK -- WHEN THE GAINING REGISTRAR ASKED -- SENT A MESSAGE OVER TO THE LOSING REGISTRAR, AS THEY WERE SUPPOSED TO, THE LOSING REGISTRAR SAID, "FINE WITH ME," BECAUSE IT HAD E-MAIL THAT LOOKED LIKE IT WAS COMING FROM THE REGISTRANT.
AND WHEN THIS WAS DISCOVERED, THERE WAS NOT A CLEAR ENOUGH TRAIL OF RECORDS TO ENABLE ALL OF THE PARTIES TO AGREE THAT THIS WAS INAPPROPRIATE AND TO SNAP BACK.
THE LOSING REGISTRAR DID NOT STEP UP TO THE PLATE AND SAY, "THIS WAS OUR FAULT AND WE SHOULD MAKE THIS RIGHT."
AND IT TOOK, AGAIN, EXTRAORDINARY AND INFORMAL ACTION BY SENIOR PEOPLE TO RESTORE THAT REGISTRATION.
HERE TOWARD THE BOTTOM OF THE SLIDE, THE GAINING REGISTRAR HAD NOTICED 80 OTHER CASES.
SO THERE WAS A PATTERN THAT THEY COULD DRAW ON.
AND IT TOOK THE CEO OF THE GAINING REGISTRAR TO STEP IN AND SAY, "THIS IS A SPECIAL CASE AND WE BELIEVE THAT WE HAVE ENOUGH INFORMATION TO OVERRIDE ALL OF THE USUAL RULES."
BUT IT'S A DANGEROUS WORLD OUT THERE.
NOW, WE DON'T HAVE GOOD STATISTICS ON HOW MANY OF THESE THINGS ARE TAKING PLACE, BUT WE DO KNOW THAT THEY'RE SERIOUS WHEN THEY DO HAPPEN.
AND IT'S A GOOD WAKE-UP CALL AND A GOOD TIME TO LOOK AT THE OVERALL SYSTEM TO SEE WHERE THERE ARE SOME WEAKNESSES.
AND AS BAD AS THESE PARTICULAR EVENTS HAVE BEEN, THEY'RE NOT AS BAD AS THINGS COULD BE.
WITH EXACTLY THE SAME MECHANISM, INSTEAD OF SHUTTING DOWN A SITE, ONE COULD INTERCEPT ALL OF THE TRAFFIC GOING TO AND FROM THE SITE AND EITHER JUST READ ALL THE MAIL AND THE WEB TRAFFIC OR MAKE MODIFICATIONS ON THE FLY.
SO IMAGINE THAT YOU'RE RUNNING A BUSINESS AND THE TRAFFIC INTO YOU IS ALL BEING SEEN BY SOMEBODY ELSE AND THEN PASSED ON TO YOU, AND ALL OF YOUR REPLIES COMING OUT ARE SEEN BY THE SAME THIRD PARTY.
AND THEN THEY CAN DO WHATEVER THEY WANT WITH THAT INFORMATION, ALL SILENTLY AND ALL WHILE IT LOOKS LIKE EVERYTHING IS WORKING FOR YOU.
AND IT'S ACTUALLY NOT SO EASY TO DETECT.
IT'S DETECTIBLE IF YOU LOOK VERY HARD.
BUT TO FIRST ORDER, IT LOOKS LIKE EVERYTHING IS WORKING.
YOU MIGHT BE A LITTLE MORE DELAY.
SOME OF THE ADDRESSES MIGHT LOOK FUNNY.
BUT A RELATIVELY SMALL PROPORTION OF THE PEOPLE IN THE WORLD WHO USE THE NETWORK HAVE EVEN A CLUE AT HOW TO LOOK AT THAT INFORMATION AND DETERMINE ANYTHING ABOUT IT.
SO WITH THAT, LET ME ASK BRUCE TO STEP IN AND TAKE YOU DOWN TO THE NEXT LEVEL.

>>BRUCE TONKIN: THANKS, STEVE.
ONE OF THE THINGS THAT WE'RE TRYING TO DO HERE, I GUESS, IS HAVE A LOOK AT WHAT ARE THE ELEMENTS OF THE SYSTEM AND WHERE ARE SOME OF THE PROBLEMS LIKELY TO OCCUR.
THIS IS REALLY JUST SORT OF SHOWING SOME OF THE PLAYERS IN THE INDUSTRY.
SO ICANN IS THE ORGANIZATION THAT HAS A CONTRACT WITH THE REGISTRY AND ALSO ACCREDITS REGISTRARS.
THERE ARE -- AND, TYPICALLY -- AND IF WE TALK ABOUT THESE IN TERMS OF ROLES, A REGISTRY HAS THE ROLE TO PROVIDE THE CENTRAL DATABASE OF THE DOMAIN NAME RECORDS.
IT HAS INFORMATION ON -- PUBLISHES INFORMATION ON WHO THE REGISTRAR IS.
AND ALSO RUNS THE TOP-LEVEL NAME SERVER.
SO IF YOU'RE LOOKING AT DOT-COM AS A TOP-LEVEL DOMAIN NAME SERVER, YOU LOOK FOR THE NEXT NAME SERVER TO SEE WHERE IT IS FOR -- A REGISTRAR BASICALLY IS -- HAS A ROLE TO ADMINISTER THE RECORDS IN THAT REGISTRY.
A SERVICE PROVIDER IN THE CONTEXT OF THIS DIAGRAM IS BASICALLY A PROVIDER THAT MANAGES THE SECONDARY NAME SERVER.
SO TYPICALLY THESE PROVIDERS USE THAT SECONDARY NAME SERVER TO PROVIDE THINGS LIKE E-MAIL AND WEB HOSTING AND WEB SITE SERVICES AND SO ON.
AND THEY TEND TO DIRECTLY CONTROL RECORDS SUCH AS THE MAIL RECORDS AND THE ADDRESS RECORDS.
NOW, A REGISTRANT MAY DEAL DIRECTLY WITH A REGISTRAR.
AND I SUPPOSE THAT'S THE TRADITIONAL MODEL THAT ICANN CONTEMPLATED.
AND THAT'S DEFINED BY THE REGISTRAR/REGISTRANT AGREEMENT.
HOWEVER, TYPICALLY, CUSTOMERS INTERACT WITH SERVICE PROVIDERS THAT PROVIDE THEM WITH THINGS LIKE E-MAIL AND WEB HOSTING SERVICES.
THAT SERVICE PROVIDER MAY HAVE AN AGREEMENT WITH THE REGISTRAR, AND THAT AGREEMENT'S TYPICALLY REFERRED TO AS A RESELLER AGREEMENT.
NOW, THESE ARE ALL DIFFERENT ROLES.
AND ONE COMPANY CAN ACTUALLY PERFORM ALL OF THESE ROLES.
SO UNTIL RECENTLY, VERISIGN, FOR EXAMPLE, PERFORMED THE ROLE OF REGISTRY, REGISTRAR, SERVICE PROVIDER, AND IN SOME CASES REGISTRANT FOR ITS OWN NAMES.
IT'S QUITE COMMON FOR A REGISTRAR TO PERFORM THE ROLES OF THE SERVICE PROVIDER, IN OTHER WORDS, RUN THE NAME SERVER.
SO IT'S VERY CONFUSING FOR AN END USER, BECAUSE ALL THEY SEE IS A COMPANY LIKE MELBOURNE I.T. OR A COMPANY LIKE VERISIGN OR A COMPANY LIKE YAHOO!, AND NOT REALLY REALIZE WHAT ROLE THEY'RE PLAYING AT THE TIME THAT THEY'RE WORKING WITH THAT COMPANY.
SO WHEN WE LOOK AT WHAT'S THE SECURITY ISSUES FOR THOSE ORGANIZATIONS, DEPENDING ON WHAT ROLE THEY'RE PLAYING, ONE OF THE THINGS THAT REGISTRIES DO IS THEY AUTHENTICATE THE REGISTRAR THAT'S TRYING TO COMMUNICATE WITH THEM.
SO, BASICALLY, A REGISTRAR PROVIDES CREDENTIALS TO A REGISTRY.
THE REGISTRY CHECKS THOSE CREDENTIALS.
A REGISTRAR CAN ADMINISTER ANY OF THE RECORDS FOR WHICH THEY'RE RESPONSIBLE ONCE THEY HAVE BEEN AUTHENTICATED.
AND CLEARLY THE ISSUE HERE IS THAT REGISTRIES NEED TO MAKE SURE THAT THEY CAN CONTROL ACCESS TO THEIR SYSTEM.
SO THEIR MOST IMPORTANT THING IS WHAT DO THEY DO TO AUTHENTICATE THE REGISTRAR COMING INTO THE REGISTRY.
AND THE MOST IMPORTANT INFORMATION HERE IS THE NAME SERVER INFORMATION THAT'S HELD FOR EACH RECORD AT THE REGISTRY.
REGISTRARS, THE PIECE OF INFORMATION THAT WE WANT TO PROTECT, I GUESS, IS THE CREDENTIALS THAT ARE USED TO ACCESS THE REGISTRY.
IF ANYONE HAS THOSE CREDENTIALS, THEY CAN GO TO THE REGISTRY AND CHANGE ANY RECORD FOR WHICH WE'RE RESPONSIBLE AND A LARGE REGISTRAR IS RESPONSIBLE FOR MILLIONS OF RECORDS.
THE RECORDS THAT WE LOOK AFTER OURSELVES ARE THINGS LIKE THE CONTACT INFORMATION FOR THE CUSTOMERS, BUT ALSO AUTHENTICATION INFORMATION FOR CUSTOMERS.
SO THAT MIGHT BE A PASSWORD, IT MIGHT BE A CREDIT CARD NUMBER, IT MIGHT BE SOME SORT OF PIECE OF INFORMATION THAT'S NOT GENERALLY PUBLIC, LIKE PERHAPS WHERE YOUR MOTHER WAS BORN OR WHERE YOUR FATHER WAS BORN OR WHAT YOUR MOTHER'S MAIDEN NAME WAS.
SO QUITE OFTEN REGISTRARS WILL COLLECT INFORMATION THAT'S NOT PUBLICLY AVAILABLE.
WE CAN ASK A QUESTION AND WHEN WE GET A RESPONSE, WE CAN SEE THAT THAT INFORMATION IS CORRECT.
THE OTHER THING WE NEED TO TRACK WHEN WE'RE -- AS A REGISTRAR IS WHAT AUTHORITY DOES THE PERSON HAVE THAT IS MAKING A REQUEST.
SO FOR A LARGE ORGANIZATION LIKE A LARGE CORPORATION, THEY MIGHT ASSIGN AUTHORITY TO ONE PERSON IN THEIR CORPORATION THAT'S ALLOWED TO CHANGE CONTACT INFORMATION.
THEY MIGHT ASSIGN AUTHORITY TO SOMEONE ELSE THAT'S ALLOWED TO CHANGE THE DNS INFORMATION.
SO REGISTRARS NEED TO LOOK AT WHAT AUTHORITY LEVELS DO THE PEOPLE WITHIN AN ORGANIZATION HAVE THAT CONTACT THAT REGISTRAR.
ONE OF THE DIFFICULTIES FOR REGISTRARS IS THAT MOST OF THE CONTACT INFORMATION WE HAVE MUST BE MADE PUBLIC.
AND THAT DOES LEAVE THIS OPEN TO SOME DEGREE.
IT MAKES IT HARDER TO AUTHENTICATE.
BECAUSE WHEN SOMEONE COMES TO US AND SAYS I'M SUCH AND SUCH A PERSON WITH SUCH AND SUCH AN ADDRESS AND THEREFORE I SHOULD HAVE THAT NAME, THEY'VE LOOKED THAT UP IN THE WHOIS, SO THAT'S NOT REALLY TELLING ME ANYTHING ABOUT WHETHER THAT PERSON IS WHO THEY SAY THEY ARE.
AND THEN WHEN THEY SAY THAT THEY -- WE SAY WELL, YOU NEED TO GIVE US YOUR PASSWORD, THEY SAY "WE'VE LOST THE PASSWORD."
SO THEN WE'RE STUCK WITH THE ISSUE OF HOW DO WE PROVE THAT PERSON IS WHO THEY SAY THEY ARE.
IN MANY CASES IT'S QUITE COMPLICATED, CHIEFLY BECAUSE THE ORIGINAL INFORMATION THAT WAS PROVIDED WAS OFTEN INCORRECT.
SO ONE OF THE MOST COMMON ISSUES FOR REGISTRARS IS THE INACCURATE DATA THAT WE HAVE ON CUSTOMERS.
AND THAT INACCURATE DATA IS OFTEN PROVIDED IN ERROR BY A REGISTRAR. -- BY A REGISTRANT.
SERVICE PROVIDERS THAT OPERATE THE NAME SERVERS THAT TYPICALLY OPERATE THE A RECORDS AND MX RECORDS QUITE OFTEN DEAL DIRECTLY WITH CUSTOMERS.
THEY HAVE ALL THE SAME AUTHENTICATION ISSUES.
THEY HAVE TO AUTHENTICATE WHO THE REGISTRATION IS.
FOR MOST OF US IN THE INDUSTRY, WE NEVER ACTUALLY PHYSICALLY SEE THE CUSTOMER.
WE DON'T HAVE FINGERPRINTS.
WE DON'T EVEN HAVE A PHOTO.
THE ONLY THING WE HAVE, TYPICALLY, IS A CREDIT CARD AND MAYBE SOME OTHER INFORMATION THEY'VE GIVEN US.
AND THAT'S ALL WE KNOW ABOUT THEM, REALLY.
AND IT'S INFORMATION THAT THEY HAVE SAID IS THEIR NAME AND ADDRESS.
SO THE MOST IMPORTANT RECORDS THAT ARE MAINTAINED HERE ARE THE RECORDS WITHIN THE NAME SERVER ITSELF, SO THE A AND MX RECORDS.
NOW, THERE ARE A FEW SECURITY ISSUES BETWEEN REGISTRARS CONNECTING TO REGISTRIES AND SERVICE PROVIDERS CONNECTING TO REGISTRARS, BECAUSE THEY'RE ALL FAIRLY MATURE I.T. ORGANIZATIONS.
THEY KNOW ABOUT SECURITY.
THEY KNOW HOW TO PROTECT THEIR CREDENTIALS.
ONCE YOU GO OUT TO THE REGISTRANT LEVEL, THOUGH, IS WHERE PROBLEMS START TO ARISE.
REGISTRANTS GENERALLY HAVE CREDENTIALS TO ACCESS THE SERVICE PROVIDER, BUT COMMONLY THEY LOSE THESE CREDENTIALS.
NOW, THESE CREDENTIALS -- A REGISTRANT MAY TAKE THE CREDENTIALS THAT THEY GET FROM A REGISTRAR AND GIVE THEM TO SOMEONE ELSE.
AND QUITE COMMONLY, YOU SEE SCENARIOS WHERE THE PERSON THAT WANTS TO CREATE A DOMAIN NAME ASKS SOMEONE ELSE TO DO IT FOR THEM, AND THAT SOMEONE ELSE ACTUALLY PUTS THEIR DETAILS INTO THE REGISTRAR, AND THEN AT SOME LATER STAGE WHEN YOU'VE LONG SINCE LOST CONTACT WITH WHO THE WEB DEVELOPER WAS AND YOU WANT TO MAKE A CHANGE TO THE REGISTRY AND YOU ASK FOR THE PASSWORD AND THE ACCESS INFORMATION, YOU CAN'T GET IT BECAUSE THE REGISTRAR HAS NO RECORD OF YOU WHATSOEVER, BECAUSE IT WASN'T YOUR INFORMATION THAT WAS PROVIDED.
AND IT WOULD BE A BIT LIKE ASKING A LAWYER TO ARRANGE THE PURCHASE OF A HOUSE FOR YOU AND THEN HAVE THAT LAWYER INSERT ALL THEIR DETAILS ON THE DEED OF TITLE FOR THAT HOUSE, AND THEN TEN YEARS LATER GO TO SELL THE HOUSE AND FIND OUT THAT YOU DON'T ACTUALLY HAVE PERMISSION TO SELL THE HOUSE; YOU DON'T OWN IT.
AND THAT IS A VERY COMMON SCENARIO IN THE DOMAIN NAME INDUSTRY IN THAT THE INDIVIDUALS OR COMPANIES THAT WISH TO HAVE A DOMAIN NAME AREN'T CLEAR THAT THEY NEED TO THEMSELVES BE REGISTERED IN THE REGISTRAR AS THE HOLDER OF THAT DOMAIN NAME.
THEY MAY WELL THEN GIVE ACCESS TO SOMEONE ELSE TO HAVE SOME CONTROL OF THE NAME, BUT THAT SHOULD BE DONE MORE AT A TECHNICAL LEVEL AND NOT ALLOWING SOMEONE ELSE TO CHANGE YOUR ADDRESS INFORMATION OR THE TITLE ON THE DOMAIN NAME.
SO ONE OF THE ISSUES THAT WITH CONTACTS, WE HAVE ADMINISTRATIVE TECHNICAL, BILLING CONTACTS.
IT'S NOT CLEAR TO CUSTOMERS WHAT THOSE CONTACTS MEAN.
QUITE COMMONLY, REGISTRANTS GIVE THE CREDENTIALS THAT ALLOW THEM TO -- ALLOW A REGISTRANT TO CONTROL EVERYTHING ABOUT A DOMAIN NAME.
THEY GIVE THESE CREDENTIALS TO ONE OF THESE CONTACTS.
AND THESE CONTACTS GENERALLY HAVE TECHNICAL KNOWLEDGE.
BUT IT'S NOT ALWAYS CLEAR WHAT THEY'RE AUTHORIZED TO DO.
BECAUSE THE REGISTRANT DOESN'T HAVE A WRITTEN AGREEMENT OR ANYTHING FORMAL THAT SAYS WHAT IS THE AUTHORITY LEVEL OF THOSE CONTACTS.
THEN WHEN YOU START LOOKING AT DOMAIN NAME TRANSFERS, ONE OF THE METHODS THAT WE USE TO AUTHENTICATE A TRANSFER IS THE E-MAIL ADDRESS THAT IS DISPLAYED BY THE REGISTRAR IN THE WHOIS.
AND THE QUESTION IS, IS THE PERSON THAT CONTROLS THAT E-MAIL ADDRESS AUTHORIZED BY YOU TO MAKE THE DECISION ON THEIR BEHALF.
AND THAT'S OFTEN NOT CLEAR.
SO COMMON REGISTRANT ISSUES ARE THAT THE REGISTRANT, YOU KNOW, THE INDIVIDUAL OR ORGANIZATION THAT WANTS A DOMAIN NAME IS NOT ALWAYS LISTED IN THE REGISTRAR AS THE OFFICIAL DOMAIN NAME HOLDER.
THERE'S POOR MANAGEMENT OF CREDENTIALS.
SO OFTEN PEOPLE HOLD PASSWORDS ON A PC OR A LAPTOP COMPUTER.
THAT, IN TURN, THEY'RE PRONE TO PHISHING ATTACKS AND SPYWARE.
THEY MAY PROVIDE THESE CREDENTIALS TO OTHER PARTIES WITHOUT REALIZE HOW MUCH CONTROL GIVING THOSE CREDENTIALS GIVES.
THERE'S A LACK OF CLEAR DELEGATION OF AUTHORITY TO THE CONTACTS.
SO THE REGISTRANT'S ASKED SOME WEB DEVELOPER OR WEB HOSTING COMPANY TO DO SOMETHING FOR THEM BUT HASN'T BEEN REALLY CLEAR ON EXACTLY WHAT ARE THEY ALLOWED TO DO, WHAT IS THE LEVEL OF AUTHORITY THAT THEY HAVE.
AND, OF COURSE, THIS GENERALLY IS REALLY BECAUSE THERE'S A LACK OF UNDERSTANDING OF THINGS LIKE THE INDUSTRY STRUCTURE, WHO ARE -- WHAT ARE THE DIFFERENT ROLES BETWEEN SERVICE PROVIDER, REGISTRAR AND REGISTRY, AND WHAT ARE THE MECHANISMS FOR TRANSFERRING CONTROL.
SO I'LL JUST GO THROUGH THE SLIDE VERY QUICKLY.
BUT WHEN WE'RE LOOKING AT WHAT'S THE MAGNITUDE OF A SECURITY BREACH, IF YOU BREACH A REGISTRY'S SECURITY, THEN YOU CAN POTENTIALLY CONTROL ALL RECORDS IN THE REGISTRY.
IF YOU BREACH THE REGISTRAR'S SECURITY ITSELF, THEN YOU CAN ACCESS ALL THE RECORDS FOR WHICH THAT REGISTRAR IS RESPONSIBLE.
AND SO ON AS YOU GO DOWN THE HIERARCHY.
USUALLY IT'S THE SECURITY OF THE REGISTRANT THAT'S BREACHED ONE WAY OR ANOTHER.
AND THEN THE DAMAGE IS OBVIOUSLY LIMITED JUST TO THE FEW RECORDS THAT THAT REGISTRANT HAS CONTROL OVER.
BUT CERTAINLY THERE'S -- AS YOU GO FURTHER UP THE CHAIN, THE NUMBER OF RECORDS AND DAMAGE, YOU KNOW, THAT RESULT IS POTENTIALLY IN THE MILLIONS.
SO TRANSFERS.
IF YOU LOOK AT TRANSFERS AT THE HIGHEST LEVEL, IT'S REALLY A TRANSFER OF CONTROL, A DIFFERENT LEVEL OF THE SYSTEM.
SO A TRANSFER CAN OCCUR BETWEEN REGISTRARS AT THE REGISTRY LEVEL.
SO, IN OTHER WORDS, A RECORD THAT'S IN THE REGISTRY CAN BE TRANSFERRED, THE CONTROL OF THAT RECORD CAN BE TRANSFERRED FROM ONE REGISTRAR TO ANOTHER.
LIKEWISE, IN A REGISTRAR, A REGISTRAR KEEPS TRACK OF WHICH SERVICE PROVIDERS ARE RESPONSIBLE FOR EACH RECORD, AND YOU CAN DO TRANSFERS AT THAT LEVEL AS WELL.
AND, FINALLY, REGISTRANTS THEMSELVES COMMONLY TRANSFER CONTROL FROM ONE INDIVIDUAL OR ORGANIZATION TO ANOTHER INDIVIDUAL OR ORGANIZATION.
AND THIS IS COMMONLY IN THE REGISTRAR INDUSTRY CALLED THE SECONDARY MARKET.
IN OTHER WORDS, SOMEONE HAS OBTAINED A DOMAIN NAME FROM A REGISTRAR, THEY HAVE THEN SOLD THAT DOMAIN TO ANOTHER PARTY. AND THAT REQUIRES A TRANSFER OF CONTROL AT THE REGISTRANT LEVEL.
SO WHAT ARE THE ISSUES GENERICALLY WITH TRANSFERS?
WELL, FIRST YOU NEED TO AUTHENTICATE WHO THE PARTIES ARE IN THE TRANSACTION.
SO WHO ARE YOU ACTUALLY TALKING TO.
THEN YOU'VE GOT THE ISSUE OF IS THE PERSON THAT YOU ARE TALKING TO -- DO THEY HAVE THE RIGHT AUTHORITY LEVEL FOR WHAT THEY ARE ASKING FOR.
IF A TECH COMES TO YOU AND SAYS I WANT TO TRANSFER THE NAME, IS THE TECH CONTACT AUTHORIZED TO MAKE THAT REQUEST.
SO THAT'S WHAT'S THE AUTHORITY LEVEL.
THE SECOND THING IS GETTING EXPLICIT AUTHORIZATION FOR WHAT THEY'RE ACTUALLY ASKING TO YOU DO.
SO ONE OF THE THINGS THAT'S BEEN APPROVED FROM THE TRANSFER POLICY IS DEFINING EXPLICIT TEXT THAT IS USED TO ACTUALLY AUTHORIZE A CHANGE.
AND THE TEXT ACTUALLY EXPLAINS WHAT CHANGE IS BEING MADE.
AND THEN, FINALLY, WHAT ARE SOME OF THE PROTECTION MECHANISMS AVAILABLE TO MAKE SURE THAT IF THERE'S A FAILURE IN AUTHENTICATION AND AUTHORIZATION, THAT THERE IS SOME OTHER PROTECTIONS AVAILABLE TO THE PARTIES IN THE TRANSACTION.
SO WITH THAT, I'LL HAND IT OVER TO RAM.
>>RAM MOHAN: THE TRANSFER PROCESS ITSELF, AS YOU CAN SEE ON THE SCREEN, CONSISTS OF MANY MOVING PARTS AND MANY DIFFERENT PLAYERS AND PARTICIPANTS IN IT.
IN FACT, IN OUR ANALYSIS, THE FACT THAT THERE ARE SO MANY MOVING PARTS, SOME OF WHICH ARE UNDER CONTRACT, REGULATED OR UNDER CONTRACT, AND OTHERS THAT ARE NOT, PARTIALLY CONTRIBUTES TO SOME OF THE COMPLEXITIES OF THE TRANSFER ISSUE AND THE PROBLEMS THAT OCCUR BECAUSE OF THE TRANSFER ITSELF.
THE PROCESS FOR TRANSFERS, THE REGISTRANT TYPICALLY REQUESTS THE REGISTRAR WHOM THEY CHOOSE -- THEY'RE CALLED THE GAIN REGISTRAR -- TYPICALLY REQUESTS TO TRANSFER A DOMAIN NAME.
AND IN SOME CASES, THE REGISTRANT ASKS THE ACTUAL ICANN-ACCREDITED REGISTRAR.
IN OTHER CASES, IT'S THEIR SERVICE PROVIDER, WHO SENDS IT TO THE REGISTRAR.
THE REGISTRAR'S TASK IS TO GET THE AUTHENTICATION FOR THAT PARTICULAR DOMAIN THAT IS BEING REQUESTED TO BE TRANSFERRED.
AND THE LOSING REGISTRAR PROVIDES AUTHENTICATION INFORMATION.
AND ONCE THAT IS RECEIVED, THE GAINING REGISTRAR REQUESTS THE REGISTRANT FOR AN AUTHORIZATION OF THE TRANSFER.
SO THERE'S A CONFIRMATION STAGE FROM THE REGISTRANT AT THAT POINT.
ONCE THE REGISTRANT DOES PROVIDE TRANSFER AUTHORIZATION, THEN THE GAINING REGISTRAR SENDS A TRANSFER REQUEST TO THE REGISTRY.
THAT THE POINT, THE REGISTRY DOES AT LEAST A COUPLE OF THINGS.
THEY -- THE REGISTRY CHECKS, IS THIS NAME LOCKED BY THE REGISTRAR, BY THE LOSING REGISTRAR?
IF THE NAME IS LOCKED, THEN YOU CANNOT ALLOW A TRANSFER.
AND THE SECOND CHECK THAT THEY TYPICALLY DO IS, IS THE AUTHENTICATION INFORMATION THAT HAS BEEN PROVIDED ACCURATE?
ONCE THEY CONFIRM OR REJECT A REQUEST, THE REGISTRY NOTIFIES THE LOSING REGISTRAR.
NOW, THE LOSING REGISTRAR TYPICALLY DOES A COUPLE OF -- AT LEAST A COUPLE OF THINGS.
IS THE DOMAIN NAME PAID FOR?
AND -- OR IS IT UNDER DISPUTE?
AND THEREFORE NEEDS TO BE LOCKED?
AND IF IT'S NOT OKAY, IF IT'S IN THOSE STATES AND IT'S NOT OKAY, THE LOSING REGISTRAR MAY REJECT THE REQUEST.
THE LOSING REGISTRAR ALSO HAS AN OPTIONAL STEP WHERE THEY MAY NOTIFY THE REGISTRANT THAT THE DOMAIN NAME THAT -- UNDER REQUEST IS GOING TO BE TRANSFERRED.
AND AT THAT POINT, THE REGISTRANT MAY REJECT THE -- THAT TRANSFER.
SO THERE ARE A FEW SAFEGUARDS THAT HAVE BEEN PLACED IN HERE.
BUT THERE ARE MANY MOVING PARTS AND A NUMBER OF GAPS THAT COME THROUGH.
AS MANY OF YOU KNOW, RECENTLY, THERE WAS A TRANSFERS POLICY CHANGE. AND THIS PROCESS SUPPORTS THE ABILITY FOR THE GAINING REGISTRAR TO INITIATE A TRANSFER AND FOR THE LOSING REGISTRAR TO REJECT THE TRANSFER REQUEST.
ONE OF THE KEY THINGS THAT HAS COME THROUGH IS A REQUIREMENT OF STANDARD TEXT TO ENSURE THAT A REGISTRANT AUTHORIZES A TRANSFER AND AUTHORIZES CANCELING A TRANSFER.
WHEN WE'RE SAYING STANDARD TEXT, WHAT WE'RE REALLY MEANING IS SOMETHING THAT IS CLEARLY IDENTIFIABLE AS STANDARD AND NORMAL AND OFFICIAL RATHER THAN A SOLICITATION TO GET A NAME TRANSFERRED FROM ONE REGISTRAR TO THE OTHER.
EXPLICIT REASONS WHY A LOSING REGISTRAR CAN CANCEL A TRANSFER AS WE SAID IN THE SCHEMATIC BEFORE ARE NONPAYMENT OF THE DOMAIN FEE OR A UDRP DISPUTE, THEREFORE RESULTING IN THE NAME BEING LOCKED.
AND IN ADDITION, THERE IS AN EXPLICIT PROTECTION MECHANISMS THAT ARE AVAILABLE TO THE REGISTRANT.
THE REGISTRANT CAN REQUEST THAT THE NAME BE LOCKED.
AND IN THE CASE OF EPP-BASED REGISTRIES, THERE IS A REQUIREMENT THAT A PASSWORD -- IT'S CALLED AN AUTHORIZATION INFO, AUTH INFO -- IS A REQUIRED PIECE OF EVERY SINGLE DOMAIN RECORD.
AND A REGISTRANT MAY CHOOSE TO MODIFY IT OR TO HOLD ONTO IT.
PRIOR INDUSTRY PRACTICE BEFORE THE TRANSFERS POLICY WAS MODIFIED, IT WAS COMMON PRACTICE FOR A LOSING REGISTRAR TO REJECT A TRANSFER WITHOUT ANY EXPLICIT AUTHORIZATION FROM THE REGISTRANT.
AND IN SOME CASES OR IN MANY CASES, THE LOSING REGISTRARS WOULD SEND A MESSAGE TO THE REGISTRANT ADVISING THEM OF THE PENDING TRANSFER.
AND IF THE MESSAGE WAS IGNORED OR MISSED OR IN SOME WAY JUST NOT SEEN BY THE REGISTRANT, THE TRANSFER WOULD BE AUTOMATICALLY REJECTED.
ONE OF THE THINGS THAT WE DID LOOK AT IN THE SECURITY COMMITTEE WAS RELATIONSHIP, IF ANY, OF THIS POLICY, THE TRANSFER POLICY CHANGE TO THE PANIX.COM INCIDENT.
AND IT DID NOT AFFECT THE PANIX.COM HIJACKING.
THE LOSING REGISTRAR IN THIS CASE DID SEND A NOTICE TO THE REGISTRANT OF THE IMPENDING TRANSFER.
WE ALSO LOOKED INTO WHAT, IF ANY, WAS THE IMPACT OF THIS POLICY CHANGE IN THE HZ.COM INCIDENT.
AND IT DID NOT AFFECT THE HZ.COM INCIDENT, EITHER.
THE REGISTRAR SENT AN E-MAIL TO THE REGISTRANT'S E-MAIL.
BUT HE DID NOT GET IT.
THE WAY WE LOOK AT IT IS THERE ARE A NUMBER OF ISSUES THAT THE INDUSTRY NEEDS TO ADDRESS AND LOOK AT.
THERE IS A LACK OF EDUCATION TO REGISTRANTS REGARDING THE AVAILABILITY OF A LOCK FUNCTION AT THEIR SERVICE PROVIDER OR AT THEIR REGISTRAR.
AND IN CASES WHERE THE AUTH INFO OR THE DOMAIN PASSWORD IS AVAILABLE, OFTEN REGISTRANTS DO NOT EVEN KNOW THAT SUCH A MECHANISM IS AVAILABLE BY DEFAULT OR THAT THEY COULD CHANGE THE AUTHORIZATION INFORMATION FOR THE DOMAIN.
IN ADDITION, WE FIND THAT THE LACK OF FACILITIES PROVIDED BY REGISTRARS AND DOMAIN NAME SERVICE PROVIDERS OR RESELLERS TO SUPPORT THE MANAGEMENT BY THE REGISTRANT DIRECTLY OF THE ABILITY TO LOCK A DOMAIN NAME AND/OR CHANGE THE AUTH INFO CODE. AND THERE'S ALSO IMPROPER USE OF LOCK AND AUTH INFO BY THE REGISTRARS.
THIS IS WHAT EXISTS TODAY.
WHAT COULD PREVENT THE PANIX.COM INCIDENT?
WHAT COULD HAVE BEEN DONE DIFFERENTLY?
THE GAINING REGISTRAR COULD HAVE PROPERLY AUTHENTICATED THE REGISTRANT AND COULD HAVE GAINED AUTHORIZATION DIRECTLY FROM THE REGISTRANT.
THE REGISTRANT COULD HAVE PLACED THE NAME ON LOCK.
THE LOSING REGISTRAR COULD HAVE CONTACTED THE REGISTRANT TO CONFIRM THAT THE TRANSFER WAS AUTHORIZED.
AND THE REGISTRY COULD HAVE IMPLEMENTED AN AUTH INFO PASSWORD MECHANISM TO MAKE SURE THERE WAS AN EXTRA STEP OF SECURITY OR INFORMATION REQUIRED FROM THE REGISTRANT.
THE HZ.COM INCIDENT, WHAT COULD HAVE BEEN DONE TO PREVENT IT?
THE LOSING REGISTRAR COULD HAVE PROPERLY ENSURED THAT THE REGISTRANT E-MAIL WAS NOT SPOOFED.
ADDITIONAL AUTHORIZATION METHODS COULD HAVE BEEN PUT IN PLACE BY THE LOSING REGISTRAR.
THE REGISTRANT AGAIN COULD HAVE PLACED THE NAME ON LOCK.
AND THE REGISTRY COULD HAVE IMPLEMENTED THE AUTH INFO PASSWORD MECHANISM.
NOW, THERE ARE SOME IMPLICATIONS TO WHAT HAPPENS WHEN THERE IS A FAILURE TO LOCK A DOMAIN NAME.
IN SOME CASES, ESPECIALLY IN THE CASE OF SOME CCTLD REGISTRIES, THE REGISTRY DOESN'T EVEN PROVIDE THE SERVICE.
AND IT'S NOT A COMMON PREVALENT PRACTICE.
IN OTHER CASES, THE REGISTRAR DOES NOT EXPLAIN THIS OPTION WELL ENOUGH TO THE REGISTRANT.
AND IT'S NOT JUST THE REGISTRAR, BUT THERE IS A LONG CHAIN HERE.
REGISTRAR TO SERVICE PROVIDER AND POTENTIALLY SERVICE PROVIDER TO OTHER SERVICE PROVIDERS BEFORE YOU ACTUALLY GET TO THE REGISTRANT.
IN OTHER CASES, THE REGISTRANT DOESN'T UNDERSTAND THE VALUE OF ACTUALLY LOCKING THE NAME, OR THE REGISTRANT CAN'T FIGURE OUT HOW TO DO IT.
IT'S TOO COMPLEX.
YOU HAVE TO CALL A NUMBER WHICH MAY OR MAY NOT BE PUBLISHED.
OR IT'S JUST TOO TECHNICALLY DIFFICULT TO DO SUCH A THING.
THE AUTHORIZATION MECHANISM ITSELF, WHAT WE'VE SEEN -- AND THIS IS OBSERVED IN THE INDUSTRY TODAY -- SOME REGISTRARS USE TODAY AND IN THE PAST HAVE USED THE SAME AUTH CODE FOR ALL REGISTRANTS, CLEARLY ALLOWING A COMPROMISE OF ANY NAME FROM ANYBODY.
SOME REGISTRARS ALSO DO NOT PROVIDE THE AUTH CODE ON REQUEST, EVEN THOUGH THEIR CONTRACT REQUIRES THEM TO.
AND IN OTHER CASES, SOME REGISTRARS PROVIDE INCORRECT AUTH CODES.
MULTIPLE TIMES, EITHER INTENTIONALLY OR BY ACCIDENT, -- WE CAN'T TELL.
OR THE REGISTRANT DOES NOT ASK FOR THE RIGHT CREDENTIALS.
IN SOME CASES WE FIND REGISTRANT ASKS -- CALLS UP OR WRITES AN E-MAIL AND SAYS, "PLEASE, SEND ME THE PASSWORD FOR MY ACCOUNT," AND THEY'RE SENT THE USER NAME PASSWORD TO LOG INTO THE ACCOUNT WHEN WHAT THEY REALLY WANTED WAS THE AUTH INFO FOR THEIR DOMAIN NAME.
AND THERE IS A DISTINCTION THERE.
AT THIS POINT, I'M GOING TO HAND IT BACK TO STEVE.

>>STEVE CROCKER: SO LET ME TURN THE ATTENTION TO WHAT HAPPENS AFTER THINGS GO WRONG.
THERE IS A FORMAL RECOVERY PROCESS, BUT IT'S PRIMARILY AIMED AT CONTRACTUAL DISPUTES.
IT DOES NOT DISTINGUISH BETWEEN THE LOSS OF USE OF A DOMAIN, THE FAILURE TO TRANSFER A DOMAIN WHEN IT'S PROPERLY AUTHORIZED, OR THE FAILURE TO MAKE CHANGES TO THE PARAMETERS OF WHERE THE NAME SERVER IS LOCATED OR OTHER KINDS OF DETAILS.
THE NATURE OF THE DISPUTE RESOLUTION IS THAT IT CAN TAKE DAYS TO WEEKS TO RESOLVE.
THIS IS THE KIND OF THING THAT'S DONE DURING OFFICE HOURS AND WITH E-MAIL SENT BACK AND FORTH, AND PERHAPS FAXES AND SIGNATURES AND SO FORTH.
SO IT'S NOT VERY WELL-TUNED TO THE KIND OF PROBLEM THAT WE'RE TALKING ABOUT HERE.
ICANN HAS AN ENFORCEMENT PRACTICE.
IT'S USUALLY DONE PRIVATELY SO IT'S NOT SO VISIBLE, IN CONTRAST TO, SAY, PRACTICES IN OTHER JURISDICTIONS.
BRUCE HAS BEEN REGALING ME WITH THE KINDS OF THINGS THAT TAKE PLACE ON THE RARE OCCASIONS THAT THERE'S ABUSE IN AUSTRALIA.
AND IT'S A MORE VISIBLE PUBLIC FLAILING OF THE BAD ACTORS.
IN AN EMERGENCY WHERE THE DOMAIN HAS BEEN DENIED, BEEN TAKEN OUT OF SERVICE, IT'S IMPORTANT TO GET IT BACK VERY QUICKLY.
THERE IS NO FORMAL PROCESS; THERE IS NO DOCUMENTED, YOU KNOW, SORT OF 911 TYPE OF SERVICE THAT YOU CAN CALL.
IF YOU KNOW THE RIGHT PEOPLE AND IF THEY'RE MOTIVATED TO HELP YOU OUT AND THEY KNOW THE RIGHT PEOPLE, THEN YOU MAY BE ABLE TO GET AN ADEQUATE NUMBER OF -- ADEQUATE HELP.
BUT THIS IS A HIT-OR-MISS SORT OF THING.
IT'S EXTRAORDINARILY EXPENSIVE.
WE'RE TALKING ABOUT FINDING KEY OPERATIONAL PEOPLE OR VERY SENIOR EXECUTIVES TO INTERCEDE ON THE BEHALF OF WHAT, AT THE END, WAS A $6 REGISTRATION FEE.
SO THE EQUATION ISN'T VERY WELL BALANCED FROM A BUSINESS POINT OF VIEW.
AND THEN THERE ARE LEGAL ISSUES. THERE'S NO CLEAR AUTHORITY ABOUT WHO'S IN CHARGE AND WHEN THINGS SHOULD BE FIXED, WHAT RISKS ARE TAKEN IF SOMEBODY INTERCEDES ON YOUR BEHALF. THERE'S NO DOCUMENTED ESCALATION PATH.
AND THE RECORDS OF WHO HELD IT, WHO HAS IT, ARE SCATTERED ABOUT AND DISTRIBUTED ACROSS THE REGISTRARS. THERE'S AN OBLIGATION FOR THOSE RECORDS TO BE MAINTAINED, BUT THERE IS NOT ANY CLEAR ENFORCEMENT OR AUDITING OR UNIFORMITY IN THOSE PROCESS.
SO ONE OF THE THINGS THAT EMERGES, QUITE OBVIOUSLY, FROM THAT KIND OF EXAMINATION IS THE POTENTIAL THAT THERE SHOULD BE A WAY OF REACHING CRITICAL PEOPLE DURING THIS TIME. AND TO BE ABLE TO TREAT THESE THINGS IN A WAY THAT'S QUITE DIFFERENT FROM THE USUAL CONTRACTUAL DISPUTES SO THAT THERE ARE 24-HOUR A DAY, 7 DAY A WEEK CONTACTS.
STEPPING BACK AND LOOKING AT THIS A BIT MORE BROADLY AND TRYING TO MAKE ANALOGIES WITH PRACTICES IN OTHER INDUSTRIES, IF YOU'RE PUT OUT OF BUSINESS FOR ANY REASON, THERE IS QUITE OFTEN BUSINESS INTERRUPTION INSURANCE, AND ONE CAN ASK THE QUESTION, WELL, WOULD IT BE POSSIBLE TO BUY AN INSURANCE POLICY OR TO BE COVERED UNDER A STANDARD BUSINESS INTERRUPTION INSURANCE. AND ONE OF THE REASONS WHY THAT -- I FIND THAT TO BE PARTICULARLY INTERESTING IS BECAUSE INSURANCE COMPANIES ARE IN THE BUSINESS OF QUANTIFYING AND UNDERSTANDING THE RISKS, AND SO THEIR REACTION, IF WE IMAGINE THAT THIS IS GOING TO BE A LARGE-SCALE BUSINESS, IS TO UNDERSTAND HOW PREVALENT THIS RISK IS AND WHAT COULD BE DONE TO PREVENT IT.
SO IF WE'RE TALKING ABOUT FIRE INSURANCE, FOR EXAMPLE, NOT ONLY DO THEY HAVE THE STATISTICS FOR FIRE, BUT THEY ALSO KNOW THAT YOUR CHANCE OF LOSS IS CONSIDERABLY REDUCED IF YOU HAVE A FIRE ALARM OR IF YOU HAVE FIRE EXTINGUISHERS, AUTOMATIC SPRINKLER SYSTEMS, OR IF YOU BUILD YOUR BUILDING OUT OF STRONGER MATERIALS.
THOSE KIND OF ANALOGIES DON'T EXIST IN ANY CLEAN FORM WITHIN THE INDUSTRY THAT WE HAVE HERE, AND ARE WORTH THINKING ABOUT.
SO THERE ARE SOME, I THINK, LONGER TERM ISSUES SIMPLY BEYOND LOOKING AT ARE THE PEOPLE WHO ARE IN PLACE AND THE CONTRACTUAL VEHICLES THAT ARE IN PLACE BEING PUSHED IN RIGHT DIRECTION.
SO HERE'S SOME TENTATIVE RECOMMENDATIONS, EMPHASIZING ONCE AGAIN THAT THIS IS AN ATTEMPT TO TELL YOU WHAT OUR THINKING IS, BUT NOT TO PUT A STAMP ON IT AND SAY WE THINK THAT WE'VE COVERED ALL THE BASES HERE.
AT THE TOP OF THE LIST IS CAMPAIGN FOR PUBLIC AWARENESS. THE KIND OF RISKS AND THE KIND OF MECHANISMS THAT ARE AVAILABLE FOR PROTECTION, AS YOU HEARD, THERE IS QUITE A LOT OF CONFUSION AND A LACK OF INFORMATION IN THE MARKETPLACE. AND WHAT WE HAVE NOT SEEN IS INDIVIDUALS OR BUSINESSES SELECTING THEIR REGISTRAR BASED UPON HOW HELPFUL THEY'RE GOING TO BE WHEN THERE'S A PROBLEM OR HOW MUCH PROTECTION THEY PROVIDE OR THEIR EASE OF USE OF THEIR LOCK AND AUTHORIZATION CODE MECHANISMS.
SO THAT'S SOMEWHAT PUZZLING. THAT COULD BE A VERY INTERESTING DIFFERENTIATOR IN THE MARKETPLACE.
ANOTHER POTENTIAL CHANGE WOULD BE AT THE END OF THE CYCLE WHERE A TRANSFER IS REQUESTED, AND THE NOTIFICATION GOES FROM THE GAINING REGISTRAR TO THE LOSING REGISTRAR, TODAY THE LOSING REGISTRAR IS NOT REQUIRED TO NOTIFY THE REGISTRANT. SOME DO AND SOME DON'T.
ONE COULD CONSIDER CHANGING THAT SO THAT THE LOSING REGISTRAR NECESSARILY SENDS THE NOTIFICATION TO THE REGISTRANT UNLESS IT HAS REASON OF ITS OWN, BECAUSE OF A CONTRACTUAL DISPUTE OR LACK OF PAYMENT OR SOMETHING, TO REFUSE THE TRANSFER.
ANOTHER RECOMMENDATION IS DEVELOPMENT OF EMERGENCY ACTION CHANNELS, SORT OF A 911 KIND OF CALL OR HOW DO YOU REACH PEOPLE IN CHARGE.
A FOURTH RECOMMENDATION IS TO CONSIDER WHETHER THE ENFORCEMENT ISSUES SHOULD BE MADE MORE VISIBLE PARTLY FOR ACCOUNTABILITY AND PARTLY BECAUSE IT WOULD HAVE AN ENHANCED EFFECT.
ONE DEVELOPMENT WHICH IS QUITE RECENT AND HAS BEEN OCCURRING IN OTHER DISCUSSIONS AT THIS ICANN MEETING IS THE DEVELOPMENT OF A POTENTIAL EMERGENCY "UNDO," RESTORE THE STATE BACK TO WHERE IT WAS ON AN URGENT BASIS. AND THAT CERTAINLY WOULD GO QUITE A LONG WAY TO IMPROVING THINGS. AND I THINK THE GENERAL MESSAGE HERE IS TO LOOK AT NOT ONLY SPECIFIC SUGGESTIONS BUT ALSO THE ENTIRETY OF ALL OF THIS.
IT'S POSSIBLE DO HARM IN THE PROCESS. WE KNOW FROM THE TRANSFERS PROCESS THAT THE -- IT WAS DIFFICULT, IN MANY CASES, TO EFFECT A TRANSFER AND THAT THE CHANGE WAS PUT IN PLACE TO MAKE IT EASIER FOR LEGITIMATE TRANSFERS TO TAKE PLACE. AND THERE IS, INHERENTLY IN ANY OF THESE TYPES OF SYSTEMS, A DEGREE OF TRADEOFF BETWEEN HOW EASY IT IS TO MAKE CHANGES WHICH THEN BRING SOME FALSE OR INAPPROPRIATE CHANGES, VERSUS HOW SAFE IS IT, WHICH THEN BRINGS A CERTAIN HAZARD THAT CHANGES THAT ARE APPROPRIATE TO MAKE ARE INHIBITED BECAUSE THEY'RE WRAPPED UP IN TOO MUCH SAFETY TAPE, IF YOU WILL.
SO THAT'S THE BREADTH OF WHAT WE WANTED TO COVER TODAY.
WE ARE WAY OVER -- WELL, WE'RE ACTUALLY ONLY A LITTLE OVER THE TIME THAT WAS ORIGINALLY SCHEDULED, AND I THINK WE'VE STAYED WELL WITHIN THE HOUR THAT WAS HERE.
SO PERHAPS IT'S APPROPRIATE IF PEOPLE WANT TO ASK A QUESTION, EITHER OF ME OR OF BRUCE OR OF RAM OR OF ANYBODY ELSE, BUT I SUSPECT THAT WE DON'T WANT TO GO VERY FAR INTO THIS TONIGHT.
>>VINT CERF: HOW DO YOU TURN THIS ON? HOW IS THAT? THAT WORKS. OKAY.
FIRST OF ALL, LET ME THANK YOU, BRUCE AND RAM, FOR PREPARING THIS INFORMATION. IT'S INCREDIBLY HELPFUL.
SECOND, IS THERE ANY INDICATION THAT THE COMMUNITY WHICH IS MOST CLOSELY INVOLVED IN THE OPERATION OF THESE FUNCTIONS, INTERESTED IN TRYING TO FIND MORE OR LESS STANDARD OR AT LEAST COMMON-PRACTICE WAYS OF DEALING WITH THEM?
AND I HAVE ONE MORE QUESTION AFTER THAT.
>>STEPHEN CROCKER: WELL, THANK YOU FOR YOUR THANKS.
WITH RESPECT TO THE COMMUNITY, AN INTERESTING PROBLEM IS EXACTLY WHAT COMMUNITY ARE WE TALKING ABOUT.
THERE ARE THREE DIGITS WORTH RESELLERS AND FIVE -- I'M SORRY, FIVE DIGITS WORTH OF REGISTRARS AND THREE DIGITS WORTH OF RESELLERS, AND THE RESELLERS, IT'S COMMONLY THOUGHT, ARE AGENTS OF THE REGISTRARS, BUT THE ACTUAL SITUATION IS MORE COMPLEX BECAUSE THEY START OUT ACTUALLY ACTING ON BEHALF OF THE REGISTRANT.
I DON'T WANT TO GET INTO ALL THE DETAILS, AND YOU KNOW PROBABLY A GREAT DEAL MORE ABOUT THAT THAN I DO, I SUSPECT, AT THIS POINT. BUT THE -- IT'S NOT CLEAR THAT WE HAVE A WELL DEFINED COMMUNITY AND THAT THEY'RE PART OF THE PROCESS SO THAT FROM THE PERSPECTIVE OF COULD WE CHANGE THE CONTRACTUAL VEHICLES OR GET EVERYBODY IN ONE ROOM, IT MAY TURN OUT TO BE A BIT TRICKIER THAN THAT.

>>VINT CERF: I WAS AFRAID YOU WERE GOING TO SAY THAT.
THE LAST QUESTION HAS TO DO GENERALLY WITH ATTEMPTS AT REMEDIES FOR THESE PROBLEMS OFTEN INTRODUCE OPPORTUNITIES FOR ABUSE THEMSELVES.
SO, FOR EXAMPLE, EMERGENCY CHANNELS AND THE LIKE, WHICH A FRANTIC PERSON CALLS AND SAYS "I'VE FORGOTTEN MY PASSWORD. THE SYSTEM ISN'T WORKING ANYMORE. PLEASE CHANGE IT ALL TO THIS DOMAIN NAME," ET CETERA, ITSELF COULD BE AN ATTACK.
SO ONCE AGAIN, WE GET INTO POTENTIALLY COMPLEX RECURSIVE PROBLEM.
I DON'T SUGGEST THIS IS GOING TO BE EASY TO FIX, BUT PLAINLY, IT WOULD BE TIMELY TO LOOK FOR ALTERNATIVE WAYS TO MAKE THIS BETTER.
>>STEPHEN CROCKER: DO YOU GUYS WANT TO COME UP AND FIELD ANY OF THESE? I DON'T HAVE ANY IDEA WHAT'S COMING HERE.
>>JORDYN BUCHANAN: FIRST A QUICK QUESTION WHICH IS DID I HEAR CORRECTLY THAT IN THE PANIX INCIDENT THE GAINING REGISTRAR DID SEND A NOTICE TO THE REGISTRANT OR NO?
>>STEPHEN CROCKER: IN THE CASE OF PANIX I THINK THEY WEREN'T EVEN BROUGHT INTO THE LOOP, ALTHOUGH I'M -- IN THE CASE OF PANIX, BRUCE --
>>BRUCE TONKIN: IS THIS -- YEAH.
THE SLIDE WAS CORRECT. RAM JUST MISSED A "NOT" IN WHAT HE SAID OR I THINK HE OMITTED THE "NOT."
THE ANSWER TO YOUR QUESTION IS THE REGISTRAR DID NOT RECEIVE A NOTIFICATION FROM THE LOSING REGISTRAR.
>>JORDYN BUCHANAN: THAT WASN'T MY QUESTION. MY QUESTION WAS DID THE REGISTRAR SEND IT.
>>BRUCE TONKIN: I BELIEVE NOT, YEAH.
>>STEPHEN CROCKER: YOU MEAN TO THE --
>>>:.
>>DAN HALLORAN: THE LOSING REGISTRAR SAID IT DID NOT SEND ANY NOTICE TO THE REGISTRANT.
>>JORDYN BUCHANAN: THERE WAS A SLIDE THAT INDICATED THAT WASN'T THE CASE, I THINK.
>>DAN HALLORAN: RAM SAID DID NOT SEND BUT HE ALSO SAID DID SEND.
>>JORDYN BUCHANAN:OKAY. I WAS CONFUSED.
I'LL KEEP IT SHORT. I WANT TO MAKE VERY BRIEF COMMENTS.
I THINK THE CURRENT TRANSFER POLICY MAKES INCIDENTS LIKE THIS EXTREMELY LIKELY. THE GAINING REGISTRAR DOESN'T HAVE THE RELATIONSHIP WITH WHOEVER IS SUPPOSED TO BE THE REGISTRANT THAT THE LOSING REGISTRAR DOES. AND BRUCE POINTED TO THIS EARLIER. IN ADDITION TO WHOIS INFORMATION, THERE'S A LOT OF OTHER INFORMATION YOU CAN USE TO AUTHENTICATE A REQUEST THAT THE GAINING REGISTRAR SIMPLY DOESN'T HAVE ACCESS TO, AND THE CURRENT PROCESS BY WHICH WE RELY ALMOST EXCLUSIVELY UPON THE GAINING REGISTRAR IS FLAWED. AND I THINK THERE ARE A NUMBER OF WAYS TO FIX IT. I HAVE A LIST BUT I DON'T WANT TO TALK ABOUT THEM RIGHT NOW.
BUT THE ONE THING I WILL SAY IS I THINK IT'S BEEN SUGGESTED -- I THINK THE SLIDES I'VE SEEN TODAY SEEM TO SUGGEST THAT LOCK IS A GOOD ALTERNATIVE, AND I THINK IT'S 100 PERCENT CLEAR TO ME THAT'S NOT WHAT LOCK WAS DESIGNED FOR AND MAYBE WHAT WE'RE KLUDGING INTO THE SYSTEM TODAY BUT LOCK IS NOT AN AUTHENTICATION MECHANISM. IT JUST HAPPENS TO BE SOMETHING WHERE WE THINK THIS IS A WAY WE THINK WE CAN FORCE PEOPLE TO AUTHENTICATE AS PART OF THE TRANSFER PROCESS.
BUT I DON'T THINK THE TRANSFER PROCESS ITSELF ANTICIPATED THAT THIS WOULD BE USED AS AN AUTHENTICATION PROCESS. I DON'T THINK THE PROTOCOL DESIGNERS ANTICIPATED THAT THAT WOULD BE THE CASE EITHER.
SO I THINK WE REALLY OUGHT TO DEVELOP A BETTER WAY TO AUTHENTICATE THESE REQUESTS THAT IS DESIGNED FOR THAT PURPOSE, BECAUSE CURRENTLY WE ACTUALLY DILUTE THE VALUE OF LOCK. THERE'S A LOT OF OTHER THINGS WE SHOULD BE USING LOCK FOR AND HAVING IT TURNED ON ACROSS THE BOARD MAKES IT DIFFICULT TO DO THAT.
SO -- AND THE ONLY OTHER THING I'LL ADD IS I'LL HEARTILY AGREE THAT I THINK WE SHOULD HAVE AN EMERGENCY UNDO MECHANISM. IN FACT, I THINK WE CAN JUST SAY IF WE USE THE CURRENT DISPUTE POLICY, ONCE THE DISPUTE IS INITIATED WE SHOULD REVERT BACK TO THE PREVIOUS STATE UNTIL THE DISPUTE IS RESOLVED. THERE'S A $65 FEE, PEOPLE AREN'T GOING TO DO THAT TO HOLD UP TRANSFERS BECAUSE THERE'S A HUGE FINANCIAL DISINCENTIVE TO DO SO. IT WILL LIKELY ONLY BE USED IN LEGITIMATE CASES.
>>BRUCE TONKIN: THANKS, JORDAN. IF I CAN COMMENT ON ONE SPECIFIC THING YOU SAID, TO BE CLEAR. YOU SAID LOCK IS NOT AN AUTHENTICATION MECHANISM. YOU ARE CORRECT. LOCK IS A FUNCTION. YOU NEED TO BE AUTHENTICATED TO LOCK AND UNLOCK. SO THEY'RE TWO DIFFERENT CONCEPTS.
SO WHAT LOCK IS IS A FUNCTION AT THE REGISTRY WHICH PREVENTS A TRANSFER. YOU ACTUALLY HAVE TO AUTHENTICATE SOMEONE BEFORE THEY CAN LOCK OR UNLOCK A NAME.
SO JUST BE CLEAR ON THAT.
>>JORDYN BUCHANAN: YEAH, UNDERSTOOD, BRUCE. I GUESS MY POINT WAS TO SAY THAT THE INTENT IN BOTH THE TRANSFER POLICY AND IN THE PROTOCOL DESIGN TO INTRODUCE LOCK WAS PROBABLY NOT TO USE IT AS A WAY TO PREVENT INAPPROPRIATE TRANSFERS, OR AT LEAST I DON'T BELIEVE THAT'S THE CASE.
>>BRUCE TONKIN: I THINK THAT'S PROBABLY -- I THINK -- I AGREE WITH YOU. IT'S A MATTER OF EVOLUTION. BUT THE LOCK WAS CERTAINLY ANTICIPATED IN THE DEVELOPMENT OF THE NEW TRANSFER POLICY BECAUSE IT DOES SPECIFICALLY MENTION IT. BUT I AGREE IN TERMS OF PROTOCOL DESIGN, LOCK HAD ANOTHER FEATURE.
JUST TO GIVE YOU A MELBOURNE I.T. POINT OF VIEW, WE HAVE DIFFERENT LEVELS OF LOCK WITHIN OUR OWN REGISTRAR SYSTEM.
SO THE REGISTRY LOCK IS VERY COARSE GRAIN. WE HAVE DIFFERENT ACCESS LEVELS. WE HAVE STAFF LOCKS AND CUSTOMER LOCKS AND RESELLER LOCKS AND YOU NEED DIFFERENT LEVEL OF AUTHENTICATION TO GET THROUGH THOSE.
SO YOU CAN'T BUILD MUCH MORE SOPHISTICATED SYSTEMS AT THE REGISTRAR END.
>>RAM MOHAN: I ALSO WANT TO CLARIFY IN THE SLIDES, IN THE CASE OF PANIX.COM, THE REGISTRAR DID NOT SEND THE NOTIFICATION BUT IN THE CASE OF HZ.COM, THEY DID SEND THE NOTIFICATION AND IT DIDN'T STOP THE NAME FROM BEING HIJACKED BECAUSE IT WAS THE -- THE E-MAIL ITSELF HAD BEEN TAKEN OVER.
AND IN THAT CASE HAD THE REGISTRAR LOCKED THE DOMAIN IT'S LIKELY THAT THAT DOMAIN WOULD NOT HAVE BEEN TRANSFERRED, EVEN THOUGH THE E-MAIL HAD BEEN COMPROMISED.
OF COURSE, GIVEN THAT THE E-MAIL IS COMPROMISED, WHOEVER DID IT COULD HAVE ASKED FOR THE NAME TO BE TAKEN OFF OF LOCK.
>>TIM RUIZ: TIM RUIZ WITH GO DADDY. IN RESPONSE TO THAT COMMENT, RAM, THE OTHER FACT IS IF THE REGISTRAR HAD BEEN ALLOWED TO DENY THE TRANSFER, IF THEY HADN'T GOTTEN ANY EXPLICIT CONFIRMATION FROM THE REGISTRANT, THAT TRANSFER WOULD NOT HAVE TAKEN PLACE AS WELL.
AND THE SAME WOULD BE TRUE, FROM WHAT I CAN UNDERSTAND, IN THE PANIX.COM CASE. IF THE REGISTRAR HAD REQUIRED CONFIRMATION AND DENIED THE TRANSFER, IF THEY HADN'T RECEIVED IT, THAT TRANSFER ALSO WOULD NOT HAVE TAKEN PLACE.
SO I GUESS ONE OF THE SUGGESTED -- ONE OF THE RECOMMENDATIONS THAT I SAW IN YOUR LAST SLIDE, STEVE, WAS ABOUT THAT POSSIBILITY OF GOING BACK TO ALLOWING THE LOSING REGISTRAR TO CONFIRM AND DENY THE TRANSFER IF THAT CONFIRMATION ISN'T RESERVED. AND I WOULD CERTAINLY SUPPORT THAT, GIVEN THAT WE'RE CONTINUING TO LIVE WITH THE EXISTING TRANSFER POLICY.
AND IN REGARDS TO LOCKS, JUST ONE COMMENT ON THAT, AND THAT'S THAT WHAT HAS -- THE RESULT OF THAT HAS BEEN THE FACT THAT WE CAN NO LONGER DENY A TRANSFER IF WE DON'T RECEIVE EXPLICIT CONFIRMATION, IS THAT NOW WE LOCK THE NAMES. IN FACT, MANY REGISTRARS ARE LOCKING NAMES BY DEFAULT, AND THE RESULT OF THAT IS THAT TRANSFERS NOW ACTUALLY START WITH THE LOSING REGISTRAR.
SO I THINK GOING FORWARD, YOU KNOW, AS WE LOOK AT MAYBE A POSSIBILITY OF A BIGGER CHANGES TO THE TRANSFER POLICY, THAT WE LOOK AT THAT POSSIBILITY AND HOW THAT COULD BE BETTER DONE WITH SOMETHING BESIDES LOCK.
>>STEPHEN CROCKER: LET ME PUT YOU ON THE SPOT A LITTLE BIT AND TURN THIS AROUND.
WHAT ARE YOUR PRACTICES WITH RESPECT TO LOCK AND AUTH IN TERMS OF ARE THEY SET AUTOMATICALLY OR -- AND WHAT INFORMATION DO YOU SUPPLY TO THE REGISTRANTS?
>>TIM RUIZ: RIGHT. WHEN WE LOCK ALL NAMES BY DEFAULT UPON REGISTRATION OR TRANSFER, WE INFORM THE REGISTRANT OF THAT UP FRONT AND WE ALSO INFORM THEM HOW THEY CAN UNLOCK IT. WE HAVE A VERY EASY UNLOCK MECHANISM. IT'S AS EASY TO UNLOCK YOUR NAME AS TO DO ANYTHING ELSE, CHANGE ANY OTHER DATA ON YOUR DOMAIN NAME.
THEY JUST LOG INTO THEIR ACCOUNT AND SELECT THE NAME AND SAY UNLOCK.
SO WE TRY TO MAKE IT AS EASY AS POSSIBLE BUT WE DO LOCK BY DEFAULT UP FRONT, BUT INFORM THE REGISTRANT OF THAT WHEN THEY'RE REGISTERING OR TRANSFERRING THE NAME.
>>STEPHEN CROCKER: THANK YOU.
>>BRUCE TONKIN: IF I COULD JUST ANSWER YOUR QUESTION, TIM, ON A PROCESS POINT OF VIEW.
THE SECURITY AND STABILITY ADVISORY COMMITTEE PROVIDES ADVICE. IT DOESN'T ACTUALLY CHANGE THE POLICY. SO IT CAN'T CHANGE THE POLICY.
THE PROCESS FOR CHANGING THE POLICY IN TERMS OF TRANSFERS SPECIFICALLY IS IN THE TRANSFERS POLICY, THE GNSO BUILT IN A REVIEW PROCESS WHICH WAS AT THREE, SIX, AND 12 MONTHS. THE THREE-MONTH PUBLIC COMMENT PERIOD OCCURRED. THERE WAS SOME PUBLIC COMMENTS OF THAT. WE HAVE YET, THE COUNCIL, GNSO, HAS YET TO RECEIVE THE REPORT ON THE THREE-MONTH REVIEW. AND WE'RE ABOUT TO COME INTO A SIX-MONTH REVIEW WHICH THE PANIX IS KIND OF IN THAT TIME FRAME.
SO I THINK WHAT I'D BE SAYING FROM A PROCESS POINT OF VIEW IS THAT AT THE SIX-MONTH POINT THE COUNCIL WILL TAKE THE ADVICE THAT THE SECURITY AND STABILITY COMMITTEE PROVIDES. IT WILL PROVIDE THE NEW PUBLIC COMMENTS AND THE SUGGESTIONS FROM YOURSELF AND JORDAN AND ANYONE ELSE THAT WANTS TO SUGGEST AND TAKE THAT ON BOARD.
THEN THE COUNCIL NEEDS TO DECIDE -- DOESN'T WANT TO CHANGE THE POLICY, BASICALLY, AND YOU AS REGISTRARS HAVE REPRESENTATIVES ON THE COUNCIL AND YOU CAN CLEARLY, WITHIN YOUR CONSTITUENCY, SAY YES, WE WANT TO CHANGE IT OR WHATEVER. THE OTHER CONSTITUENCIES, LIKEWISE, THE BUSINESS CONSTITUENCY, ISPS AND SO ON, HAVE INPUT INTO THAT DECISION.
SO DOES THAT MAKE THAT CLEAR, THE PROCESS?
>>TIM RUIZ: YES, ABSOLUTELY. THANK YOU.
>>SAMUEL WEILER: SAM WEILER, FIRST I USED TO BE A FAN OF THE UNDO APPROACH, BUT AS I'VE BEEN STANDING HERE IN THIS QUEUE I'VE BEEN THINKING ABOUT WAYS I COULD ABUSE THAT TO DENY MY COMPETITORS EFFECTIVE USE OF THEIR DNS.
AND I WOULD URGE THE SSAC TO EXERCISE EXTREME CAUTION IN RECOMMENDING AN UNDO APPROACH. THAT'S NOT SAYING YOU SHOULDN'T DO IT; JUST BE CAUTIOUS.
>>STEPHEN CROCKER: THANK YOU.
>>SAMUEL WEILER: SECOND, YOUR RECOMMENDATION SLIDE HAD TWO CLASSES, ONE HAD TO DO WITH FUZZY, SOCIAL AUTHENTICATION. AND I'M CONCERNED AS WE GO THROUGH THE SOCIAL AUTHENTICATION PATH WE ACTUALLY MAKE IT EASIER FOR DOMAINS TO GET HIJACKED IN THE INTEREST OF PROTECTING THOSE WHO ARE IRRESPONSIBLE AT MANAGING THEIR AUTHENTICATION CREDENTIALS.
I THINK IT WOULD BE USEFUL FOR THE COMMUNITY TO MAKE A DECISION AS TO WHETHER OR NOT WE INTEND THESE AUTHENTICATION CREDENTIALS TO BE BEARER INSTRUMENTS. IF YOU HAVE THE AUTHENTICATION FOR THIS DOMAIN, YOU OWN IT, NO QUESTIONS ASKED.
>>STEPHEN CROCKER: THERE'S -- AS YOU KNOW FROM -- BECAUSE I KNOW A LOT ABOUT THE EXPERIENCE THAT YOU HAVE, WHEN YOU DESIGN THESE SYSTEMS, THERE'S -- IT'S IMPOSSIBLE TO HAVE PERFECTION. YOU HAVE AN INHERENT TRADEOFF OF TYPE ONE AND TYPE TWO ERRORS, YOU HAVE EASE OF USE VERSUS HOW STRONG THEY ARE. AND WE'RE LIVING IN KIND OF A PRACTICAL WORLD HERE. WE COULD TALK ABOUT BIOMETRICS AND SEALED SYSTEMS AND ALL SORTS OF THINGS, AND ALL THAT WOULD DO IS RAISE THE EXPENSE AND MAKE IT EXTREMELY HARD TO TRANSFER WHEN YOU WANT.
AND THAT WOULD BE ONE END OF THE EXTREME, AND THEN THE OTHER END IS A WIDE-OPEN SYSTEM WHERE IT'S EASY TO TRANSFER BUT VERY HARD TO PROTECT.
SO THERE IS A, NECESSARILY, A DESIGN PROCESS HERE. AND HUMANS ARE PART OF THE DESIGN PROCESS WHICH IS WHY THE SOCIAL ASPECT IS IN THERE. I DON'T KNOW A WAY OUT OF THAT, SO RATHER THAN TRY TO ESCAPE IT, IT SEEMS MORE APPROPRIATE TO TRY TO EMBRACE IT AND INCLUDE THAT AS PART OF THE SYSTEM.
BUT IT ISN'T, FOR US, AS A SERIES -- AS A HANDFUL OF EXPERTS SITTING HERE TO TRY TO DESIGN THE SYSTEM AND IMPOSE IT. IT'S REALLY A MATTER OF RAISING THE ISSUES, GIVING IT OUR BEST SHOT IN TERMS OF WHAT THE IDEAS AND WHERE THERE IS NO CLEAR ANSWER, TO LAY OUT WHAT THOSE TRADEOFFS ARE. AND THEN LEAVE IT TO THE PEOPLE WHO HAVE THE RESPONSIBILITY OF SERVING THE COMMUNITY, THE REGISTRIES, THE REGISTRARS, ALL THE SERVICE PROVIDERS. BECAUSE WHATEVER, YOU KNOW, WE DECIDE IS GOOD IN THEORY, THE PRACTICE WILL TURN OUT TO BE SOMEWHAT DIFFERENT, AT LEAST.
>>SAMUEL WEILER: THEN I'LL RESTATE MY CONCERNS AS A REGISTRANT.
>>STEPHEN CROCKER: I'M SORRY?
>>SAMUEL WEILER: I'M GOING TO RESTATE MY CONCERNS AS A REGISTRANT. I FIND IT DISTURBING THAT ICANN WOULD CONTEMPLATE MECHANISMS THAT MAKE IT EASIER FOR MY DOMAINS TO BE HIJACKED IN THE INTEREST OF PROTECTING THOSE WHO CANNOT RELIABLY MANAGE THEIR OWN AUTHENTICATION CREDENTIALS.
>>STEPHEN CROCKER: WELL, LET ME CALL YOUR ATTENTION TO ONE OF THE THINGS THAT WE SAID, WHICH WAS THAT IT MAY BE DESIRABLE TO HAVE DIFFERENT MECHANISMS, DIFFERENT LEVELS OF PROTECTION IN ORDER TO PROVIDE STRONGER PROTECTION WHERE THE REGISTRANT, EITHER BECAUSE IT'S AN EXTRAORDINARILY KNOWLEDGEABLE AND CLUEFUL PERSON LIKE YOURSELF OR, SAY, A LARGE ESTABLISHED COMPANY THAT HAS THE RESOURCES AND HAS THE NEED TO HAVE VERY STRONG PROTECTION OF ITS DOMAIN, EITHER BECAUSE IT MAY BE A TARGET OR BECAUSE IT HAS VERY HIGH VALUE.
AND I DON'T HAVE A FULL PICTURE OF HOW ALL THIS COULD PLAY OUT, BUT IT OPENS UP THE SPACE CONSIDERABLY SO THAT YOU DON'T HAVE TO NECESSARILY HAVE A ONE SIZE FITS ALL.
>>BRUCE TONKIN: IF I CAN JUST COMMENT A BIT FURTHER ON THAT. YOU ARE ASSUMING THERE'S A ONE SIZE FITS ALL THERE FROM THE POINT OF VIEW OF THE REGISTRANT AND THERE'S NOT. MELBOURNE I.T. AND ANY OF THE LARGER REGISTRARS THAT SPECIALIZE IN CORPORATE CLIENTS HAVE MUCH STRONGER AUTHENTICATION SYSTEMS FOR A REGISTRANT TO DO ANYTHING. AND WE HAVE THE NAMES ON LOCK. SO I JUST WANT TO MAKE IT CLEAR, YOU'RE SAYING HOW DO YOU PROTECT THE REGISTRANT AND AUTHENTICATION INFORMATION. YOU TELL ME WHAT AUTHENTICATION YOU WOULD LIKE TO USE; RIGHT? IF YOU SIGN AN AGREEMENT WITH ME AND SAY YOU ONLY WANT TO MAKE A CHANGE TO THIS NAME IF YOU COME AND USE YOUR FINGERPRINT ON A THUMB PRINT READER IN MY OFFICE, I'M HAPPY TO SIGN THAT AGREEMENT WITH YOU AND I'LL CHARGE YOU FOR THAT SERVICE.
SO YOU'RE IN CONTROL OF THAT WHEN YOU CHOOSE YOUR REGISTRAR.
>>SAMUEL WEILER: IT SOUNDS LIKE WE HAVE TO INSTITUTIONALIZE THESE MECHANISMS, THOUGH, BETWEEN REGISTRARS.
>>BRUCE TONKIN: I'M MISSING THE POINT. SORRY.
CAN YOU EXPLAIN THAT?
>>SAMUEL WEILER: IT SOUNDED TO ME LIKE WITH THE GAINING REGISTRARS DOING THE AUTHENTICATION, THESE MECHANISMS HAVE TO BE STANDARDIZED.
>>BRUCE TONKIN: WELL, THE GAINING -- LET'S BE CLEAR. THERE IS AN ABILITY TO LOCK DOWN THE NAME AT THE REGISTRY, AND THAT IS IN THE CONTROL OF THE REGISTRANT; RIGHT?
SO YOU CAN LOCK THAT DOWN. AND TO PICK UP ON TIM'S POINT, YOU CAN DEFINE WHAT THE AUTHENTICATION IS TO UNLOCK IT. THAT'S IN YOUR CONTROL.
YOU CAN HAVE AN AGREEMENT WITH A REGISTRAR THAT SAYS "LOCK MY NAME" AND I CAN TELL YOU IT'S LOCKED, AND THEN YOU CAN DEFINE WHATEVER AUTHENTICATION YOU LIKE. AT THAT POINT, THE GAINING REGISTRAR IS IRRELEVANT BECAUSE IT CAN NEVER TRANSFER A NAME.
>>RAM MOHAN: IF I COULD ADD, WE'VE BEEN TALKING ABOUT REGISTRARS, BUT IN MANY, MANY CASES THE REGISTRANT DOESN'T KNOW THE DIFFERENCE BETWEEN A REGISTRAR, A RESELLER, THE SERVICE PROVIDER, THEIR ISP, ANY OF THOSE THINGS. AND THE AVERAGE REGISTRANT DOES NOT NECESSARILY UNDERSTAND, IS CLUEFUL ABOUT HOW TO TRANSFER A NAME OR HOW TO UNLOCK OR THINGS LIKE THAT.
SO ONLY THE TECHNICAL PIECE OF IT I FEAR MIGHT BE MISSING. PERHAPS THE LARGER PROBLEM HERE, WHICH IS THAT IT'S NOT JUST REGISTRARS WHO ARE INVOLVED IN THIS, AND IT'S NOT JUST CLUEFUL REGISTRANTS WHO ARE INVOLVED IN THIS PROBLEM. THE PROBLEM REALLY -- AND IN THE CASE OF PANIX, CLEARLY YOU HAD CLUEFUL FOLKS ON BOTH SIDES. IT STILL HAPPENED.
>>SAMUEL WEILER: PRESUMABLY IT MIGHT NOT HAPPEN IF WE HAD STRONGER TECHNICAL ENFORCEMENT OF THE AUTHENTICATION.
>>BRUCE TONKIN: AND ENFORCEMENT IS THE IMPORTANT PART.
TO PICK UP ON TIM'S POINT EARLIER, HE WAS SAYING, YOU KNOW, THINGS WOULD HAVE BEEN BETTER IF THE LOSING REGISTRAR HAD BEEN REQUIRED TO AUTHENTICATE THE TRANSFER.
BUT SO WOULD HAVE BEEN BETTER -- PANIX.COM WOULDN'T HAVE HAPPENED IF ANY OF OTHER THREE THINGS HADN'T HAPPENED EITHER.
THERE ARE FOUR LEVELS OF PROTECTION THERE.
TIM IS FOCUSING ON THE FOURTH LEVEL.
HE IS ASSUMING THAT THE THREE OTHER LEVELS HAVE FAILED.
AND YOU CAN JUST KEEP ADDING MORE AND MORE BELTS AND BRACES AND, EVENTUALLY, YOU HAVE TO LOOK AT THE COST OF CONTINUOUSLY ADDING THOSE.
>>STEVE CROCKER: IN FAIRNESS, LET'S MOVE ON HERE.
THANK YOU.
>>RON SHERWOOD: GOOD EVENING, GENTLEMEN.
THANK YOU FOR A FINE PRESENTATION.
MY NAME IS RON SHERWOOD.
I LISTENED CAREFULLY TO WHAT YOU SAID.
BUT I SUSPECT THAT THE EXAMPLES THAT YOU GAVE ARE RELATIVELY RARE COMPARED WITH OTHERS THAT CAN BE VERY MUCH MORE COMMON.
FOR EXAMPLE, GO BACK TEN YEARS, IF YOU WILL, AND CERTAINLY ANYTIME OVER THE LAST TEN YEARS, YOUR AVERAGE REGISTRANT IS NOT UNDERSTANDING OF THE PROCESSES.
AS RAM EXPLAINED, THE DOMAINS WERE OFTEN REGISTERED BY A FRIEND, A COLLEAGUE, AN "I KNOW HOW TO DO IT" TYPE OF GUY, OR IN SOME CASE, CPAS OR ATTORNEYS OR FAILED ISPS.
UNDER THOSE CONDITIONS, FREQUENTLY, THE TECHNICAL CONTACT AND THE ADMINISTRATIVE CONTACT WERE THE NAME OF THE PERSON WHO MADE THE REGISTRATION, NOT THE REGISTRANT.
UNDER THOSE CONDITIONS, THE REGISTRANT NOW FINDS HIMSELF IN A POSITION WHERE HE IS UNABLE TO GET AWAY FROM SUCH A PERSON.
AND AN EXAMPLE THAT I HAVE, THE -- I AM GOING TO CALL HIM THE CPA -- CHARGES $360 A YEAR FOR THE ONE-TIME RENEWAL.
AND THERE IS NO WAY THAT THE REGISTRANT CAN CHANGE THAT, EVEN PROVIDING ALL THE INFORMATION TO, IN THIS CASE, VARIO, WHO ARE NOW ABSOLUTELY CONVINCED THAT HE IS THE REGISTRANT, OWNS THE NAME, AND IS ENTITLED TO CHANGE.
THEY END UP, AFTER BEING CONVINCED, ENDING, NOT AS RAM SUGGESTED, A MESSAGE TO THE REGISTRANT TO CONFIRM THAT THEY WANT THE CHANGE, BUT A MESSAGE TO THE TECHNICAL OR ADMINISTRATIVE CONTACT ASKING IF THEY WANT TO CHANGE.
AND THE ANSWER IS "NO."
HOW DO WE OVERCOME THIS?
>>STEVE CROCKER: YOUR POINT IS ABSOLUTELY RIGHT.
AND THAT'S WHY PART OF WHAT HAS TO HAPPEN, WE THINK, IS AN AWARENESS OF WHO THE PARTIES ARE.
AND THERE MAY NEED TO BE SOME IMPROVEMENT IN THE RECORD-KEEPING WHEN YOU BUY -- YOU KNOW, AS WE TALKED, WHEN YOU BUY A PIECE OF PROPERTY, THERE IS A VERY EXPLICIT TITLE USUALLY. AND ONE DOESN'T MOVE INTO THE HOUSE AND HAVE PAID A LOT OF MONEY WITHOUT HAVING A PIECE OF PAPER THAT'S REGISTERED IN THE RIGHT PLACE, EVEN IF THERE ARE ATTORNEYS INVOLVED OR OTHER HELPERS ALONG THE WAY.
DOMAIN NAMES HAVE NEVER BEEN TREATED AT THAT LEVEL OF CARE AND THAT LEVEL OF METICULOUSNESS IN THE RECORD KEEPING FROM A LEGAL PERSPECTIVE AND FROM A RECORD-KEEPING PERSPECTIVE.
AND SO THAT IS ANOTHER AVENUE TO PURVIEW THAT DEALS EXACTLY WITH YOUR SITUATION.
AND THERE ARE PLENTY -- YOU'RE ABSOLUTELY RIGHT, THERE ARE PLENTY OF CASES WHERE CONTROL OF A DOMAIN NAME HAS EFFECTIVELY BEEN LOST BECAUSE THE TECHNICAL CONTACT OR THE ADMINISTRATIVE CONTACT IS NO LONGER EITHER ACCESSIBLE OR COOPERATIVE OR MAY EVEN HAVE PASSED AWAY.
AND THEN WHERE ARE YOU?
>>BRUCE TONKIN: YEAH, I THINK --
>>STEVE CROCKER: $360 WOULD BE CHEAP IF IT COMPARED TO TRYING TO RAISE THE DEAD.
>>RON SHERWOOD: MY QUESTION IS, HOW DOES THE REGISTRANT RECOVER FROM THIS?
>>STEVE CROCKER: AND I DON'T KNOW THAT THERE ARE ANY WELL-DEFINED WAYS TO DO THAT TODAY.
AND THAT BECOMES A PIECE OF THE OVERALL SET OF THINGS THAT PROBABLY NEED TO BE ADDRESSED IN THE EXAMINATION OF THIS ISSUE.

>>RAM MOHAN: IF I COULD JUST ADD A COMMENT.
IN THE SYSTEM TODAY, IF A ADMINISTRATIVE CONTACT SAYS, "NO, DO NOT TRANSFER A NAME" AND THE REGISTRANT SAYS "YES, TRANSFER THE NAME," THE NAME GETS TRANSFERRED.
THE ADMINISTRATIVE TECHNICAL CONTACT DOES NOT HAVE THE SAME POWER OR ABILITY TO STOP THE NAME TRANSFER THAT A REGISTRANT DOES.
>>RON SHERWOOD: IN THIS PARTICULAR CASE, THAT DOES NOT HAPPEN.
THE -- IN THIS CASE, VARIO IS CONVINCED THAT THE REGISTRANT OWNS THE DOMAIN, BUT THEY WILL NOT CHANGE IT UNTIL THEY GET THEIR STANDARD PROCEDURE.
THEY SEND A MESSAGE TO THE ADMINISTRATIVE CONTACT OR THE TECHNICAL CONTACT, AND THEY GET BACK A NEGATIVE ANSWER.
AND THEIR POLICY STATES QUITE CLEARLY, IF WE DO NOT GET A POSITIVE ANSWER, WE WILL NOT EVEN COMMUNICATE WITH YOU AGAIN.
>>CHUCK GOMES: IF I CAN HELP HERE, ONE SCENARIO -- IT DEPENDS WHO IS LISTED AS THE REGISTRANT.
KEEP IN MIND THAT HIS CPA COULD HAVE REGISTERED THE CPA AS THE REGISTRANT.
>>RON SHERWOOD: THAT IS NOT THE CASE.
>>CHUCK GOMES: WHAT RAM IS SAYING IS THAT IF YOU CAN SHOW THAT YOU ARE THE REGISTRANT, YOU SHOULD BE ABLE TO GET THAT CHANGED.
>>RON SHERWOOD: WE HAVE DONE THAT.
AND VARIO IS CONVINCED THAT WE ARE THE REGISTRANT, OR MY CLIENT IS, AND STILL THEY GO THROUGH THE PROCESS OF SENDING A REQUEST TO --
>>BRUCE TONKIN: WE CAN PROBABLY TAKE IT OFFLINE.
I'D BE HAPPY TO TALK TO YOU TO GIVE YOU SOME IDEAS HOW TO HANDLE IT.
AT THE GENERAL LEVEL, THE POLICY SPECIFIES THAT THE REGISTRANT HAS PRIORITY. AND AS CHUCK IS POINTING OUT, OFTEN WHAT HAPPENS IS THE REGISTRANT IS NOT STORED IN ANYBODY'S RECORDS.
SO THAT'S ONE THING.
IF THE REGISTRANT IS STORED IN THE RECORD AND HE CAN PROVE IT, THEN PROBABLY ONE OF THE EASIEST THINGS TO DO IS TO GO TO THE LOSING REGISTRAR AND CHANGE THE ADMIN AND TECH CONTACTS.
BECAUSE YOU SHOULD BE ABLE TO GET THE CREDENTIALS TO DO -- THIS IS KIND OF WHERE WE'RE TALKING ABOUT CREDENTIALS.
YOU SHOULD BE ABLE TO GET ISSUED CREDENTIALS FROM THE REGISTRAR THAT'S CURRENTLY OF RECORD W THOSE CREDENTIALS, YOU CAN CHANGE THE TECH AND ADMIN CONTACTS TO ANYTHING THAT YOU LIKE.
THEN YOU CAN GO TO ANOTHER REGISTRAR, CAUSE PRESUMABLY THE CREDENTIALS ARE NOW YOURS OR THE AUTHENTICATION INFORMATION IS NOW YOURS, AND THEN THE TRANSFER WOULD GO THROUGH.
BUT LET ME TAKE IT OFFLINE WITH YOU AND I'LL KIND OF UNDERSTAND THE CASE A BIT CLEARER.
>>RON SHERWOOD: THANK YOU.

>>JON NEVETT: JON NEVETT FROM NETWORK SOLUTIONS.
WE'D LIKE TO AGREE WITH YOUR SOLUTION THAT WE REQUIRE THE LOSING REGISTRAR TO SEEK CONFIRMATION FROM THE REGISTRANT IN THE CASE OF A TRANSFER.
BUT WE'D LIKE TO YOU GO ONE STEP FURTHER, WHICH IS CONSISTENT WITH WHAT TIM FROM GO DADDY, AND JORDYN FROM REGISTER.COM ARGUED, WHICH IS THAT THE REGISTRANT MUST AFFIRMATIVELY RESPOND IN ORDER TO EFFECTUATE THE TRANSFER.
WE HAVE SEEN CASES -- NOT PANIX.COM, NOT HERTZ -- BUT CASES OF HIJACKING THAT WOULD HAVE BEEN PREVENTED IF THE REGISTRANT WAS REQUIRED TO AFFIRMATIVELY RESPOND.
NOW, I UNDERSTAND THAT ONE OF THE GOALS OF THE NEW TRANSFER POLICY WAS TO FACILITATE TRANSFERS.
OBVIOUSLY, WITH THAT EASING OF FACILITATION, YOU'RE GOING TO HAVE SOME ADDITIONAL HIJACKING.
I WOULD ARGUE THAT WE SHOULD USE THE ANALOGY OF THE AMERICAN CRIMINAL JUSTICE SYSTEM WHERE IT'S BETTER TO HAVE TEN GUILTY PEOPLE GO FREE THAN ONE INNOCENT INDIVIDUAL GO TO JAIL.
IT'S BETTER FOR TEN REGISTRANTS TO HAVE THE MINOR INCONVENIENCE OF REISSUING A TRANSFER REQUEST THAN TO HAVE ONE PANIX.COM TYPE OF SITUATION OR ONE HIJACKING SITUATION WHERE THE RESULTS ARE TREMENDOUS AND THE IMPACTS ARE TREMENDOUS.
IT'S -- YOU ASKED FOR THE INPUT OF FOLKS WHO ARE CLOSEST TO THIS.
YOU HAVE NOW HAD THE THREE OF THE FIVE LARGEST REGISTRARS UP HERE ARGUING THAT WE SHOULD HAVE THE MOST -- WE SHOULD HAVE THE AFFIRMATIVE CONSENT OF THE REGISTRANT IN ORDER TO EFFECTUATE A TRANSFER.
THANK YOU.
>>STEVE CROCKER: IF THE FORCE OF YOUR COMMENT IS THAT THE TRANSFER POLICY SHOULD BE REVERTED BACK TO THE WAY IT WAS BEFORE, I THINK THE CHANCES OF THAT ARE -- IS SOMEWHERE BETWEEN SLIM AND NONE.
BUT THEY ALSO ARE NOT ANYWHERE CLOSE TO WHAT WE ARE TRYING TO SUGGEST IS THE PROPER PATH.
>>BRUCE TONKIN: A COUPLE OF QUESTION COMMENTS, A QUESTION -- A COUPLE OF QUESTIONS AND THEN YOU CAN RESPOND.
FIRSTLY, DID YOU ADVISE ICANN OF THOSE SCENARIOS?
BECAUSE ONE OF THE THINGS THAT WE NEED AT THE GNSO IS INFORMATION.
AND, YOU KNOW, WHEN I'VE ASKED THE QUESTION FOR ICANN, I'M HEARING THERE'S HARDLY ANYTHING.
AND YOU'VE SAID --
>>JON NEVETT: ACTUALLY, ICANN ADVISED US OF IT AND ALERTED US TO THE SITUATION.
>>BRUCE TONKIN: AND SECONDLY, ARE YOU SEEING THE SAME INCIDENTS OF THESE IN REGISTRIES THAT USE AUTH INFO?
THIS IS REGISTRIES THAT DO NOT.
>>JON NEVETT: I'M SORRY?
>>BRUCE TONKIN: SOME REGISTRIES, LIKE DOT BIZ AND DOT INFO --
>>JON NEVETT: IT WAS DOT-COM.
>>BRUCE TONKIN: SO THEY HAVE HIGHER LEVELS OF AUTHENTICATION. AND COM AND NOT PRESENTLY DO NOT.
MY QUESTION TO YOU IS DO YOU SEE A DIFFERENCE BETWEEN THOSE TWO ENVIRONMENTS?
>>JON NEVETT: YEAH, I'D AGREE WITH YOU ON THAT.
THERE'S MORE WITH DOT INFO.
>>BRUCE TONKIN: AT THE POLICY LEVEL, IT WAS ENVISAGED THAT AUTH INFO WOULD BE PROGRESSIVELY INTRODUCED.
AND I BELIEVE THE DOT-COM REGISTRY WILL BE DOING THAT.
SO THE QUESTION IS SHOULD WE BE BASICALLY WAITING FOR THIS TO COME INTO EFFECT FOR COM AND NET BEFORE ACTUALLY CHANGING THE POLICY AND ADDING OTHER LAYERS?
JUST INTERESTED IN YOUR VIEW.
>>JON NEVETT: WE CAN TAKE A LOOK AT THAT.
BUT TODAY NAMES COULD BE HIJACKED BECAUSE OF WHAT WE PERCEIVE AS A NEGATIVE ASPECT OF THE NEW TRANSFER POLICY.

>>RAM MOHAN: THE SSAC, ONE JUST COMMENT HERE.
I THINK THE SSAC RECOMMENDATIONS ARE TO CONSIDER MAKING THE LOSING REGISTRAR NOTIFY THE REGISTRANT, CONSIDER MAKING THAT MANDATORY.
BUT I DON'T THINK OUR RECOMMENDATION AT THIS POINT IS ACTUALLY TO MAKE -- TO DENY THE TRANSFER AUTOMATICALLY IF THE REGISTRANT DOES NOT --
>>JON NEVETT: I ABSOLUTELY UNDERSTAND YOUR RECOMMENDATION THAT YOU PUT ON THE SCREEN WAS JUST TO MANDATE THAT THE LOSING REGISTRAR SOLICIT CONFIRMATION.
I THINK YOU SHOULD TAKE IT ONE STEP FARTHER AND SAY LOSING REGISTRAR, YOU MUST SOLICIT THE REGISTRANT AND GET CONFIRMATION.
AND IF YOU DON'T GET AFFIRMATIVE CONSENT, THEN THE TRANSFER DOESN'T GO THROUGH.
>>RAM MOHAN: RIGHT.
I THINK WE'VE MADE THE FIRST PART OF THAT AS A RECOMMENDATION RATHER THAN THE SECOND.
>>JON NEVETT: YEAH.
>>ALAN LEVIN: HI.
ALAN LEVIN, I'M THE CHAIRMAN OF INTERNET SOCIETY, SOUTH AFRICAN SOCIETY.
UNFORTUNATELY, ONE OF MY AFRICAN BROTHERS CAME ACROSS A REALLY DIFFICULT SITUATION WHICH WAS DESCRIBED EARLIER ON WHERE HIS REGISTRAR HAD LOCKED HIS DOMAIN NAME BY DEFAULT.
AND HE WASN'T QUITE SURE HOW TO GET IT UNLOCKED TO CHANGE REGISTRAR.
AND I TRIED TO ASSIST HIM. AND TO BE COMPLETELY HONEST, AFTER MONTHS OF TRYING VARIOUS TYPES OF ACTIVITIES, CALLING UP THE REGISTRAR, E-MAILING THE REGISTRAR, LOGGING IN, RE-LOGGING IN, I EVEN HAD TO TAKE OVER HIS E-MAIL ADDRESS IN ORDER TO TRY AND RESOLVE THIS, IT WAS ABSOLUTELY IMPOSSIBLE FOR ME TO DO THIS WITHOUT CALLING IN A PERSONAL FAVOR.
SO I AM NOT ADVOCATING FURTHER AUTHENTICATION.
I THINK IT CAN BE ABUSED.
BUT I WOULD LIKE TO APPEAL TO ICANN TO PLEASE, AS THE LICENSING OR ACCREDITATION AUTHORITY, FOR THOSE REGISTRARS THAT DON'T PLAY FAIR, THEY NEED TO BE PUNISHED OR SOMETHING.
I WOULD LIKE TO HOLD YOU ACCOUNTABLE FOR THIS.
I'D ALSO LIKE TO APPEAL TO YOU AS ICANN TO PLEASE CREATE SOME KIND OF USER FRIENDLY MECHANISM FOR THOSE END USERS IN AFRICA OR ANYWHERE ELSE THAT ARE FAR AWAY TO BE ABLE TO ADDRESS SUCH AN ISSUE.
THANK YOU.

>>BOB CONNELLY: I'M BOB CONNELLY.
I'M DRAWING UPON EXPERIENCE AT PSI JAPAN.
I THINK SOME OF YOUR DETAILS ARE SOMEWHAT SIMPLISTIC, BECAUSE IN MY KNOWLEDGE, IN MY EXPERIENCE, VERY FEW ADMINISTRATIVE CONTACTS ARE ACTUALLY THE REGISTRANT.
THEY'RE IN THE HANDS, IN THE PSI JAPAN OPERATION, PRIMARILY OF LARGE ISPS.
THEY ARE THE ADMINISTRATIVE, THE TECHNICAL, AND THE BILLING CONTACT.
SO IT'S RATHER -- I THINK YOU'RE SKEWED IN THE WRONG DIRECTION IN MUCH OF YOUR PRESENTATION.
THAT SAID, WE HAVE ENCOURAGED PEOPLE TO USE A LOCK.
BUT THE RECOMMENDATIONS OF THE TRANSFER PROGRAM REQUIRE AN EASY WAY TO UNLOCK, WHICH BASICALLY IS AS DANGEROUS AS THE PASSWORD WHICH ALLOWS YOU TO MAKE THE TRANSFER IN THE FIRST PLACE.
SO WE THINK THERE SHOULD BE -- AND BRUCE HAS INDICATED YOU DO IMPLEMENT A SECOND LEVEL OR A THIRD LEVEL WHICH WOULD NOT BE SIMPLY MANIPULATED BY A DISGRUNTLED EMPLOYEE TO THE DISADVANTAGE OF HIS FORMER EMPLOYER.
I'D ALSO LIKE TO COMMENT ON THE STATEMENT THAT, WELL, THERE'S ONLY $6 INVOLVED; YOU CAN'T AFFORD TO DO THIS.
IN MOST BUSINESSES, IT'S PRETTY COMMON YOU FIND THAT 90% OR 99% OR ALMOST ALL OF YOUR PROBLEMS COME FROM ONE OR TWO CUSTOMERS.
SO YOU CERTAINLY MUST HAVE A SYSTEM WHICH ALLOWS YOU TO DIVERT SOME OF THOSE FUNDS TO THE DIFFICULT PROBLEM.
THANK YOU.

>>TIM RUIZ: TIM RUIZ OF GO DADDY.
I JUST WANTED TO SAY, BRUCE, THAT YOUR POINT ABOUT THE LEVELS -- EXCUSE ME -- IS WELL TAKEN.
I JUST WOULD LIKE TO MAKE ONE OTHER POINT ABOUT THE CONCEPT OF, YOU KNOW, THE LOSING REGISTRAR GETTING CONFIRMATION, THEN EVEN GOING FURTHER, AS JON STATED, AND ACTUALLY REQUIRING CONFIRMATION FROM THE REGISTRANT.
IT'S A PROVEN PROCESS THAT MANY OF THE TOP TEN REGISTRARS HAVE BEEN USING FOR A LONG TIME.
IT DID PREVENT A LOT OF PROBLEMS.
AND I THINK THAT THE FOCUS OR THE FIRST FOCUS SHOULD BE ON PREVENTION.
I'M CERTAINLY IN AGREEMENT THAT, YOU KNOW, EMERGENCY MEASURES TO TAKE CARE OF IT WHEN IT DOES HAPPEN, BECAUSE IT'S CERTAINLY GOING TO HAPPEN IN THE FUTURE, IS FINE, BUT THE FOCUS SHOULD BE PRIMARILY ON PREVENTION.
AND WE KNOW -- YOU KNOW, WE'VE PROVEN THAT THIS IS ONE VERY GOOD PREVENTATIVE MEASURE.
AND ONE THING WE LEARNED IN THE REGISTRARS MEETING EARLIER TODAY, OR PERHAPS IT WAS YESTERDAY, AND THAT'S THAT WHAT'S HAPPENED IN A LOT OF CASES, LIKE SOME OF YOU HAVE HIJACKING INSTANCES JON REFERRED TO, SOME THAT WE'VE HAD, IS THAT THE REGISTRARS INVOLVED SETTLE THIS BETWEEN THEMSELVES.
THEY JUST QUICKLY TAKE CARE OF IT BETWEEN THEMSELVES, THEY CALL EACH OTHER, COME TO AGREEMENT, THE TRANSFER IS REVERSED AND THEY COME TO -- IT'S TAKEN CARE OF.
IN A LOT OF CASES THOSE FALL BETWEEN THE CRACKS AS FAR AS ICANN IS CONCERNED.
THEY'RE NOT DOCUMENTED AND THEY DON'T KNOW ABOUT IT.
AS REGISTRARS, I THINK WE NEED TO DO A BETTER JOB OF KEEPING TRACK OF THAT INFORMATION AND MAKING SURE ICANN GETS IT.
>>STEVE CROCKER: THANK YOU.
TINA, IT'S PERFECT.
YOU GET THE LAST WORD.
>>TINA DAM: IT'S NICE.
I ALSO NOTICE EVERYBODY WANTS TO LEAVE AND GET OUT OF HERE.
I UNDERSTAND THAT.
I JUST WANT TO MENTION A COUPLE THINGS.
IN THE PREVIOUS SESSION BEFORE THIS, IT WAS SPECIFIED THAT ICANN DOES NOT DEVELOP POLICIES.
WELL, WE DO NOT DECIDE ON POLICIES, NOT AT THE ICANN STAFF LEVEL.
AND THAT -- THIS NEW TRANSFER POLICY IS ALSO NOT SOMETHING THAT'S BEEN DECIDED BY ICANN STAFF; IT'S BEEN DEVELOPED UP THROUGH THE COMMUNITY OVER SEVERAL -- INPUTS FROM SEVERAL SUPPORTING ORGANIZATIONS AND OVER A FEW YEARS.
IF WE DON'T HEAR FROM THE COMMUNITY ABOUT THE SPECIFIC PROBLEMS YOU HAVE, WHETHER IT'S PROBLEMS WITH THE EXISTING POLICY OR IF IT'S PROBLEMS THAT RELATES TO GOING BACK TO A PREVIOUS POLICY, THEN WE DON'T -- WE DON'T REALLY HAVE THE RIGHT OPPORTUNITY TO FIGURE OUT WHAT TO DO ABOUT IT.
SO I MENTIONED AT THE REGISTRAR CONSTITUENCY YESTERDAY, IF YOU SEE THOSE HIGH NUMBER OF HIJACKINGS, WELL, THEN COME AND TELL US ABOUT IT BECAUSE I HAVEN'T HEARD ABOUT IT. AND AS LONG AS I HAVEN'T HEARD ABOUT IT AND SEEN THOSE STATISTICS, I JUST REALLY CAN'T SEE THAT THAT'S TAKEN PLACE.
SO COME TO US AND TELL US ABOUT IT.
THE SECOND THING IS ENFORCEMENT. I'M ONE OF THE ICANN STAFF PERSONS WHO HAS BEEN ACTIVELY WORKING ON ENFORCING THE NEW TRANSFER POLICY TOWARDS SPECIFICALLY REGISTRARS WHO ARE TRYING TO MAKE IT DIFFICULT FOR THEIR CUSTOMERS TO LEAVE AND MOVE TO ANOTHER REGISTRAR OF CHOICE.
WE ACTUALLY DO ENFORCE THE POLICY. AS WAS MENTIONED AT THE PRESENTATION TODAY, THE ENFORCEMENT IS NOT VISIBLE. WE HAVEN'T REALLY BEEN GOOD AT MAKING IT -- MAKING DETAILS OF IT AVAILABLE TO THE PUBLIC, AND THAT'S SOMETHING WE'LL BE LOOKING INTO, BUT WE DO HAVE ENFORCEMENT IN PLACE.
SO FOR THOSE WHO HAD SPECIFIC PROBLEMS, PLEASE COME TO ME AFTER THE SESSION AND I'LL TRY TO EXPLAIN TO YOU AND HELP YOU INTO UNDERSTANDING HOW THIS NEW POLICY IS ACTUALLY WORKING BETTER FOR YOU.
>>BRUCE TONKIN: TINA, CAN YOU ALSO JUST COMMENT, IF YOU'RE ABLE TO, ON THE, I GUESS, TRANSFERS REPORT FROM THE FIRST THREE-MONTH REVIEW. ARE YOU ABLE TO COMMENT ON WHAT PORTION -- DID YOU HAVE COMPLAINTS ABOUT PEOPLE NOT BEING ABLE TO TRANSFER VERSUS COMPLAINTS ABOUT PEOPLE SAYING IT WAS TOO EASY? I JUST WANT TO UNDERSTAND WHAT THE BALANCE WAS. BECAUSE THE REASON WHY THE GNSO LOOKED AT THE TRANSFERS POLICY, TIM MENTIONED THAT THERE WAS AN EFFECTIVE SYSTEM TO STOP TRANSFERS, AND THAT'S TRUE, BUT THERE ARE ALSO MANY COMPLAINTS ABOUT THAT AND THAT'S WHY THE GNSO LOOKED AT THE POLICY.
SO I'M TRYING TO UNDERSTAND, IS THAT STILL THE CASE, WHAT'S CHANGED? ARE WE NOW GETTING LOTS OF COMPLAINTS ABOUT IT BEING TOO EASY? BECAUSE WE HAVE TO HAVE DATA TO MAKE DECISIONS.
>>TINA DAM: SURE; I UNDERSTAND THAT. FIRST LET ME POINT OUT THAT THAT REPORT IS GOING TO BE ON THE WAY -- I WOULD ESTIMATE CERTAINLY WITHIN THE NEXT 24 HOURS.
SECONDLY, THE NUMBER OF COMPLAINTS, YOU KNOW, WE RARELY HEAR ANYTHING ABOUT THINGS THAT ARE EASY FOR PEOPLE. WE ALWAYS HEAR THINGS WHEN IT'S DIFFICULT.
THE MAIN COMMENTS AND QUESTIONS AND COMPLAINTS WE'VE RECEIVED IN REGARDS TO THE NEW TRANSFER POLICY HAS BEEN IN REGARDS TO UNDERSTANDING IT; REALLY, UNDERSTANDING HOW IT'S FUNCTIONING AND HOW IT'S STANDARDIZED PROCESSES ARE FUNCTIONING WITHIN THAT NEW POLICY. AND THAT HAS BEEN BOTH FROM REGISTRANTS AND REGISTRARS.
SO WHAT WE'VE BEEN TRYING TO DO AND WHAT I CERTAINLY WOULD BE THE FIRST PERSON TO REALIZE IS THAT WE NEED TO CONTINUE DOING, AND MAYBE BE BETTER AT DOING, IS TO EDUCATE THE COMMUNITY. BUT I SAW THAT AS ONE OF YOUR RECOMMENDATIONS AS WELL AND THAT'S SOMETHING WE'RE TAKING INTO EFFECT AS WE'RE WORKING ON REVIEW OF A POLICY LIKE THIS.
BUT IT'S REALLY, IT'S BEEN CLARIFICATION, UNDERSTANDING THAT YES, YOU CAN UNLOCK YOUR NAME IF YOU WANT TO; YES, YOU NEED TO HAVE AN AUTHORIZATION CODE, AND YES, THE REGISTRAR DOES NEED TO GIVE THAT TO YOU WHEN YOU ARE ASKING THEM. BASIC INFORMATION LIKE THAT HAS BEEN THE MAIN PROBLEM.
>>BRUCE TONKIN: AND I THINK THE ISSUE, I SUPPOSE, IN TERMS OF STOPPING THE -- I SUPPOSE IMPROVING THINGS IS ENFORCEMENT ALL AROUND, BECAUSE EVEN IF YOU DO AS SUGGESTED, WHICH IS TO MAKE THE LOSING REGISTRAR DO THE AUTHENTICATION, IF THE LOSING REGISTRAR DOESN'T DO THEIR JOB PROPERLY IT STILL STOPS THE REGISTRANT FROM DOING WHAT THEY WANT TO DO AND ULTIMATELY THAT'S REALLY THE BALANCE. THE REGISTRANT NEEDS TO DO WHAT THEY WANT TO DO AND WE NEED TO HAVE A PROCESS THAT ALLOWS THEM TO DO THAT. LIKEWISE WE NEED TO AUTHENTICATE WE KNOW IT'S THE REGISTRAR ASKING US THAT.
IF ANY OF THE PLAYERS IN THE MARKET -- IT DOESN'T MATTER IF IT'S GAINING OR LOSING -- DOESN'T DO THEIR JOB, THEN IT NEEDS ENFORCEMENT.
>>TINA DAM: YEAH. ENFORCEMENT IS SOMETHING WE'RE LOOKING CLEARLY INTO.
JUST A FEW DAYS AGO ICANN PUBLISHED A PROGRAM FOR COMPLIANCE WITH REGISTRIES AND REGISTRARS, AND SO IT'S SOMETHING WE'RE TAKING MUCH MORE INTO CONSIDERATION AS WE GET THE STAFFING FOR IT.
I ALSO WANTED TO MENTION ONE MORE THING ABOUT THE NUMBER OF COMPLAINTS IN REGARDS TO TRANSFERS.
BEFORE THE NEW TRANSFER POLICY, WE HAD, I WOULD SAY, HUGE NUMBERS OF COMPLAINTS FROM END USERS WHO WERE NOT ABLE TO GET AWAY FROM A REGISTRAR WHO THEY THOUGHT DID NOT PROVIDE THE SERVICE THAT THEY NEEDED SIMPLY BECAUSE THERE WAS NO STANDARDIZED PROCESS IN PLACE AND NO MECHANISM.
FOR EXAMPLE, THERE WAS NO MECHANISM FOR ICANN TO STEP IN AND SAY "YOU HAVE TO LET THIS REGISTRANT OR CUSTOMER OF YOURSELF TRANSFER." WE DO HAVE THAT IN PLACE RIGHT NOW SO I THINK IT'S VERY SUCCESSFUL.
THAT SAID, I OF COURSE WANT TO HEAR FROM THOSE WHO THINK IT'S NOT SUCCESSFUL, BUT I SPECIFICALLY WANT TO SEE STATISTICS AND EXAMPLES IT HAVE.
>>STEPHEN CROCKER: YEAH, I -- SPEAKING FOR US, I THINK WE FULLY APPRECIATE THAT THERE WAS A BROAD SCALE OF UNHAPPINESS AMONG REGISTRANTS WHO COULDN'T TRANSFER AS EASILY AS THEY THOUGHT, AND A PERCEPTION THAT THERE WAS ABUSE AMONG SOME OF THE REGISTRARS.
SO GOING BACKWARDS IS NOT AN EASY OPTION AT ALL. AND THE MAN STANDING NEXT TO YOU HAS JUST REGALED US WITH A TALE OF EXACTLY THAT KIND OF THING THAT HAS NOT BEEN RESOLVED.
SO THE ISSUES ARE SORT OF AT THE NEXT LEVEL OF, OKAY, WE FIXED THE SORT OF BROAD-SCALE PROBLEM, MAKE IT EASIER TO TRANSFER AND REDUCE SOME OF THAT PAIN, BUT NOW THERE'S STILL A SET OF ISSUES TO DIG INTO.
THANKS.
>>JORDYN BUCHANAN: I JUST WANT TO MAKE ONE REALLY, REALLY SHORT COMMENT. I KNOW WE ALL WANT TO GET OUT OF HERE, BUT OUR EXPERIENCE IS ACTUALLY BECAUSE OF THE WIDE SCALE PREVALENCE OF LOCKING THAT THE SUCCESS RATE OF TRANSFERS IS DOWN POST NEW TRANSFER POLICY, NOT UP. SO PORTABILITY, THERE'S NO -- THERE'S NOT A LOT OF TALK IN THE TRANSFER POLICY ABOUT REGULARIZING THE DELOCKING PROCESS. -- SORRY, SORRY, YOU'RE RIGHT, BRUCE. THE PREVALENCE OF LOCKING HAS MADE IT HARDER TO TRANSFER THAN IT WAS BEFORE, NOT EASIER. AND THERE'S NO -- THERE'S NOT VERY MUCH LANGUAGE IN THE TRANSFER POLICY ABOUT THE REQUIREMENTS. IT SAYS YOU HAVE TO HAVE A WAY TO UNLOCK BUT IT DOESN'T SAY YOU CAN'T PUT UP A HUGE BUTTON THAT SAYS IF YOU CLICK THIS BUTTON TO UNLOCK YOUR MOM IS GOING TO DIE. SO A LOT OF THE BAD BEHAVIOR THAT EXISTED BEFORE, SENDING OUT NOTICES THAT LOOK LIKE ADVERTISEMENT, CAN STILL EXIST AROUND THE UNLOCK. SO I DON'T THINK IT'S EASY TO SAY WE FIXED THE PORTABILITY PROBLE!
M BECAUSE I DON'T THINK IT'S NECESSARILY RESOLVED.
>>RAM MOHAN: JORDYN, BEFORE WE GO AWAY, A QUESTION. IF YOU SAY THAT AUTH INFO -- WHEN THERE WAS AUTH INFO PRE-TRANSFER POLICY CHANGE, WAS THERE A SIMILAR TYPE OF A TRANSFER -- LOW TRANSFER SUCCESS RATE AS OPPOSED TO POST LOCK? BECAUSE IT SEEMS TO ME AUTH INFO DOES PROVIDE THAT EXTRA VERIFICATION STEP THAT THE LOCK IS ATTEMPTING TO PROVIDE. WHAT'S YOUR EXPERIENCE?
>>JORDYN BUCHANAN: I DON'T HAVE THOSE SPECIFIC DATA POINTS SO I CAN'T ANSWER YOUR SPECIFIC QUESTION BUT I WOULD AGREE WITH YOU I WOULD BE PERFECTLY SATISFIED IF THE SOLUTION TO THE PROBLEM WAS TO HAVE AUTH INFO CODES EVERYWHERE, INCLUDING IN COM AND NET BECAUSE THE STATUS QUO COM AND NET POLICY IS INADEQUATE FROM THE SECURITY PERSPECTIVE.
>>STEPHEN CROCKER: THANK YOU.
ALAN.
>>ALAN LEVIN: WELL, IT SOUNDS LIKE THERE ISN'T MUCH AGREEMENT HERE.
I THINK I DON'T REALLY UNDERSTAND THE TERM ENFORCEMENT. DOES ENFORCEMENT MEAN THAT WE WILL MAKE IT HAPPEN OR DOES IT MEAN THAT WE ARE PUNISHING THOSE THAT ARE STOPPING IT FROM HAPPENING?
I'M ASKING FOR SOME LEVEL OF PUNISHMENT FOR THOSE THAT BLOCK IT, BECAUSE OBVIOUSLY THERE IS ONLY ONE COMPLAINT FOR EVERY HUNDRED PROBLEMS.
>>STEPHEN CROCKER: I THINK THE PERSON YOU WANT TO HAVE A GOOD DISCUSSION WITH IS RIGHT NEXT TO YOU THERE.
>>TINA DAM: YES. PUNISHMENT OF REGISTRARS THAT DOES NOT FOLLOW THE TRANSFER POLICY BASICALLY MEANS THAT THEY'RE IN THE IN COMPLIANCE WITH THEIR REGISTRAR ACCREDITATION AGREEMENT WITH ICANN. AND IF THAT COMES TO OUR ATTENTION, WE WILL ASK THEM TO MAKE CHANGES -- WELL, ACTUALLY, WHAT HAPPENS WHEN WE RECEIVE A COMPLAINT FROM A REGISTRANT, WE WILL FIRST OF ALL MAKE SURE THAT THE SPECIFIC CASE IS SOLVED IMMEDIATELY, AND THEN SECOND OF ALL, WE'LL GO IN AND RESEARCH THAT AND MAKE SURE THAT THE PROCESSES THAT THAT REGISTRAR HAS IN PLACE IS IN COMPLIANCE WITH THEIR AGREEMENT WITH ICANN.
AND PART OF THAT AGREEMENT IS A TRANSFER POLICY OF HOW YOU CAN TRANSFER BETWEEN REGISTRARS AND THAT'S A CONSENSUS POLICY AND IT'S REALLY AS EASY AS THAT.
SO AGAIN, GIVE ME THE INFORMATION, SEND THE INFORMATION TO ME, CALL ME, GRAB ME AS WE'RE WALKING OUT OF THIS ROOM AND IF YOU ANY SPECIFIC PROBLEMS, I'LL BE HAPPY TO HELP SOLVE IT.
>>BRUCE TONKIN: I'LL JUST COMMENT FROM A POLICY DEVELOPMENT POINT OF VIEW BECAUSE YOU MENTIONED PUNISHMENT AND I SUPPOSE THERE ARE DIFFERENT STEPS THERE. WHAT ICANN DOES AT THE MOMENT IS SEEK TO FIX THE PROBLEM AS OPPOSED TO PUNISH. SO OUR FOCUS IS TO CONTACT THE PARTIES, GET THEM TO FIX THE PROBLEM AND MAKE SURE THEY'RE IN COMPLIANCE WITH WHATEVER THE POLICY MIGHT BE. SO THAT'S ONE EMPHASIS.
ANOTHER EMPHASIZE IS TO SAY, WELL, PERHAPS THERE NEEDS TO BE SOME -- USING YOUR TERM -- PUNISHMENT MECHANISMS.
AND ONE OF THE THINGS THE GNSO COUNCIL IS LOOKING AT IS JUST THIS GENERAL AREA OF COMPLIANCE AND LOOKING AT WHAT POLICIES NEED TO BE IN PLACE THERE.
SO, FOR EXAMPLE, IF I -- IN AUSTRALIA, WHERE I'M FROM, IF I DRIVE A CAR TOO FAST, I WOULD TYPICALLY GET FINED THE FIRST TIME, $100.
AND THEN I'M ALSO ALLOWED A CERTAIN NUMBER OF TIMES THAT I CAN POSSIBLY GET FINED.
AND THEN IF I DO IT TOO MANY TIMES, I ACTUALLY LOSE MY DRIVER'S LICENSE.
BUT ICANN AT THE MOMENT BASICALLY ONLY HAS ONE PUNISHMENT MECHANISM, AND THAT'S TO REVOKE THE LICENSE.
AND THAT'S A PRETTY BIG STEP WHEN IT MIGHT ONLY BE, YOU KNOW, FOR A LARGE REGISTRAR LIKE MELBOURNE I.T, WE'RE DOING MILLIONS OF TRANSACTIONS, AND AN ERROR IS MADE IN ONE TRANSACTION, IT'S A PRETTY BIG THING TO PULL A LICENSE.
BUT I AGREE WITH YOU, IT WOULD BE PERFECTLY REASONABLE TO FINE US SOME AMOUNT AND MAKE THAT PUBLIC AND SAY, YOU KNOW, WE FIND THIS REGISTRAR X AMOUNT OF DOLLARS.
IN THE SAME WAY, SOME OF THE REGISTRIES HAVE SERVICE-LEVEL AGREEMENTS WITH THE REGISTRARS AND THEY SAY WE'RE GOING TO PROVIDE A SERVICE OF 99% RELIABILITY, WHATEVER IT IS.
AND SOME OF THEM WILL ACTUALLY GIVE US A REFUND IF THEY DON'T.
SO THAT'S A NICE INTERMEDIATE STEP TO ICANN ACTUALLY COMING AND REMOVING THE ACCREDITATION TO THE REGISTRY.
SO I AGREE WITH YOU.
BUT TO BE FAIR TO ICANN, WE, AS THE COMMUNITY HERE, HAVE TO DEVELOP THAT POLICY.
AND THAT POLICY THEN NEEDS TO GO INTO CONTRACTS.
AND TINA, I GUESS STANDING HERE BEING THE TARGET FOR THE ICANN STAFF, CAN IMPLEMENT THAT POLICY.
BUT SHE CAN ONLY DO WHAT WE ASK HER TO DO, WHAT THE RULES ARE, BASICALLY.
>>TINA DAM: CAN I ADD A LITTLE BIT TO THAT?
IT TAKES TIME WHEN YOU MAKE CHANGES TO POLICIES, BECAUSE IT HAS TO BE IMPLEMENTED THROUGHOUT THE COMMUNITY.
SO RATHER THAN JUST TAKING REGISTRARS ACCREDITATION AGREEMENT AWAY, WHICH I THINK WOULD BE A LITTLE TOO DRASTIC, WE'RE REALLY TRYING TO WORK WITH THE REGISTRARS TO MAKE THE SYSTEM WORK IN THE CORRECT WAY.
AND, SECONDLY, I ACTUALLY BELIEVE THAT THERE WAS A PART OF THE RECOMMENDATION THAT WENT FROM THE GNSO COUNCIL TO THE ICANN BEFORE THE NEW POLICY THAT WAS IMPLEMENTED THAT HAD A SMALL PART IN IT WHERE IT WAS GOING TO BE POSSIBLE FOR US TO ACTUALLY HAVE OTHER OPTIONS IN PLACE IN CASES WHERE REGISTRARS CONTINUED TO VIOLATE THE POLICY.
AND IT'S NOT SOMETHING THAT'S IN PLACE WITH THE POLICY AS IT IS RIGHT NOW.
BUT PERHAPS IT'S SOMETHING WE CAN WORK WITH THE GNSO COUNCIL AS WE REVIEW THE POLICY.
AND LOOK INTO THAT.

>>ALAN LEVIN: I'M SORRY.
JUST AS A LAST REMARK.
I SENSE THAT MAYBE THIS AREA HASN'T BEEN EXPLORED AS MUCH AS I PREVIOUSLY THOUGHT.
I THINK THAT IT'S A REALLY GOOD IDEA TO PUBLISH, IF AN INVESTIGATION HAS HAPPENED AND A REGISTRAR HAS BEEN AT FAULT, PUBLISH THAT.
MAKE THEM -- HOLD THEM PUBLICLY ACCOUNTABLE FOR NOT ADHERING.
IT'S A PUNISHMENT THAT I THINK IS A FAIR PUNISHMENT, THAT'S APPROPRIATE FOR OUR COMMUNITY.
AND I THINK THAT REGISTRARS WILL BE MORE DILIGENT AT REPORTING OTHER REGISTRARS THAT AREN'T ADHERING.
BECAUSE THE REGISTRARS ARE THE ONES THAT KNOW BETTER THAN ANYBODY ELSE, BECAUSE, AS A REGISTRANT, I WILL GO TO MY RECEIVING REGISTRAR BEFORE I'LL GO TO ICANN, BECAUSE I KNOW THEY'LL BE ABLE TO RESOLVE IT A WHOLE LOT QUICKER.
THEY'RE RESPONSIVE, THEY'RE A BUSINESS, AND THEY DO.
THEY MAKE IT HAPPEN.
AND SO I SENSE THAT IF YOU MAKE IT PUBLIC, IT'S A REALLY GOOD WAY OF HOLDING REGISTRARS ACCOUNTABLE.
AND REGISTRARS WILL HOLD EACH OTHER ACCOUNTABLE FAR QUICKER.
>>STEVE CROCKER: SO PUBLICITY IS A VERY GOOD THING.
ASKING ICANN TO DO THIS IS PERFECTLY APPROPRIATE.
BUT, EQUALLY, I FIND IT INTERESTING THAT THERE AREN'T -- THERE HASN'T BEEN A SELF-ORGANIZATION OF -- A CONSUMER REPORTS TYPE OF REPORTING AND COMPARISON OF REGISTRAR PRACTICES.
THERE'S NOTHING THAT PRECLUDES THE COMMUNITY AS A WHOLE FROM DOING THESE THINGS, EVEN WITHOUT THE INSTRUMENT OF THE CONTRACTUAL CONTROL.
SO THANK YOU VERY MUCH.
A FEW OF YOU HAVE STAYED TO THE BITTER END HERE.
AND WE ALL APPRECIATE IT.
I HOPE THIS HAS BEEN HELPFUL TO EVERYBODY.
AND AS I SAID AT THE OPENING, THIS IS A FIRST STEP FOR US.
AND WE WILL CONTINUE TO GATHER MATERIAL.
AND OUR TARGET IS TO DELIVER A FINAL REPORT ON THIS, HOPEFULLY BY THE LUXEMBOURG MEETING.
THANK YOU.

(APPLAUSE.)