ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>FREDERICO NEVES: THIS IS THE DNSSEC WORKSHOP.
MY NAME IS FREDERICO NEVES, AND ON BEHALF OF THE DNSSEC WORKING GROUP DEPLOYMENT, I AM DOING THIS PRESENTATION.
SO, WHAT IS DNSSEC?
THIS IS THE DNS PROTOCOL, THE DNS SYSTEM, THE ONE THAT WE -- MOST OF THE OTHER (INAUDIBLE) OF THE INTERNET FIND HOSTS.
AND IT PROVIDES AUTHENTICATION, INTEGRITY, AND SECURE DENIAL OF EXISTENCE.
THE DOCUMENTS EXPLAIN THIS TECHNOLOGY HAVING BEEN PUBLISHED LAST WEEK.
THIS IS THE THIRD REWRITE OF THESE DOCUMENTS, SO IT'S IN CONSIDERATION OF BEING QUITE MATURE.
AND IT HAS BEEN IN IETF FOR THE LAST (INAUDIBLE) YEARS.
AND IT'S CONSIDERED AN ENABLING TECHNOLOGY FOR SCALING INTERNET SECURITY.
THE DNSSEC DEPLOYMENT INITIATIVE STARTED IN 2004, AND LAST FEBRUARY, WE HAD A (INAUDIBLE), AND WE HOLD PHYSICAL MEETINGS AT --
THE OBJECTIVES OF THE GROUP IS TO INCREASE AWARENESS OF THE TECHNOLOGY AND OUTREACH, TRY TO INCENTIVE ADOPTION.
WE TRY TO TRACK ISSUES AND PROBLEMS WITH THE PROTOCOL, ESPECIALLY ON DEPLOYMENT.
AND WE HAVE A ROADMAP.
AND WE HAVE PARTICIPATION FROM CCTLDS, GTLDS, VENDORS, GOVERNMENTS.
MOSTLY EVERYBODY THAT IS INTERESTED IN DNSSEC IS JOINING THIS GROUP.
OKAY.
THE DNSSEC ROADMAP.
IT'S A LIVE DOCUMENT.
THE FIRST VERSION IS AVAILABLE ON THE WEB SITE.
THIS IS THE WEB SITE, WWW.DNSSEC-DEPLOYMENT.ORG.
YOU CAN FIND THE ROADMAP IS A PDF FILE AND MOST INFORMATION, MAILING LIST, IT'S AVAILABLE IN THIS SITE.
AND LAST, BUT NOT LEAST, THIS IS A CALL TO PEOPLE TO PARTICIPATE, TO JOIN THIS EFFORT TO TRY TO GET BETTER SECURITY.
AND WE SHOULD BE DOING THIS NOW, NOT IN -- WHEN WE GET SOME MINOR PROBLEMS RESOLVED IN THREE OR FOUR YEARS.
WE SHOULD START THIS NOW.
AND CONTINUING DURING THIS MORNING, WE WILL HAVE MORE PRESENTATIONS AND A PANEL.
AND HERE'S THE AGENDA.
-- I DON'T KNOW IF IT'S GOOD DOWN THERE.
BUT THE NEXT PRESENTER IS BILL MANNING, DOING THE MAN-IN-THE-MIDDLE ATTACK DEMO.
LATER WE WILL HAVE RUSS MUNDY WITH THE DNSSEC OVERVIEW, THE PANEL WITH DEMI GETSCHKO, TALKING ABOUT THE ROOT.
SOME CCTLDS AND GTLDS.
WE WILL HAVE CONSIDERATIONS FROM PAT KANE ABOUT LARGER REGISTRIES' DNSSEC DEPLOYMENT.
LATER, TWO PRESENTATIONS FROM ED LEWIS, ONE ON EPP, THE PROVISIONING PROTOCOL, EXTENSIONS TO DNSSEC, A PRESENTATION ABOUT CERTIFICATES, ENUM, AND OPEN DISCUSSION.
LET'S START, BILL.
>>BILL MANNING: OKAY.
GOOD MORNING.
THERE'S A LITTLE BIT OF SETUP GOING ON HERE BECAUSE WE ARE GOING TO RUN A LIVE -- WE'RE GOING TO TRY AND RUN A LIVE DEMO.
AND WE WANT YOUR PARTICIPATION.
OKAY.
SO A FEW SLIDES TO BEGIN WITH.
THIS DEMO THAT WE ARE GOING TO DESCRIBE IS AN ACTIVE ATTACK ON THE DNS INFRASTRUCTURE.
THIS WAS WRITTEN BY A COUPLE OF EX-STUDENTS OF MINE.
IT'S BEEN RUN A COUPLE OF TIMES, ONE AT A ENGINEERING -- WHAT THEY CALL A WIDE CAMP IN JAPAN.
AND, AGAIN, AT THE APRICOT MEETING A COUPLE OF MONTHS AGO.
THE GENTLEMAN WHO DID MOST OF THIS WORK IS FUJIWARA KASUNORI, WHO IS UNABLE TO BE HERE.
SO I'M PRESENTING ON HIS BEHALF.
AND IF WE HAVE A WORKING NETWORK TODAY, I WILL DEMONSTRATE DNS SPOOFING.
THIS IS NOT QUITE THE SAME AS A PHISHING ATTACK.
THIS IS MORE EFFECTIVE.
THE DEMO WE WILL USE TODAY CHANGES THE SSID.
IF YOU WOULD LIKE TO PARTICIPATE AND THE NETWORK IS WORKING, YOU WILL FIND AN SSID IN YOUR -- AVAILABLE TO YOU CALLED "BAD BOY."
AND I ENCOURAGE YOU TO THINK ABOUT PARTICIPATING.
AND IF SO, YOU WILL WANT TO CHANGE YOUR NETWORK INFRASTRUCTURE.
IF YOU DON'T WANT TO PARTICIPATE, JUST LEAVE THINGS WHERE THEY ARE.
BRIEFLY, ATTACKS TO THE DNS, YOU CAN DO DENIAL OF SERVICE ATTACKS ON THE SERVERS, YOU CAN SEND A WHOLE LOT OF QUERIES TO THE SERVERS.
THIS, ESSENTIALLY, BECOMES A DISTURBANCE THAT YOU CAN'T DO A WHOLE LOT ABOUT.
IT'S LIKE A FLOODING ATTACK.
BUT THE ATTACKER GETS NO BENEFIT FROM SIMPLY TAKING OUT YOUR DNS.
THERE'S NO REAL BENEFIT THERE FROM A COMMERCIAL SIDE.
DNS DATA SPOOFING, ON THE OTHER HAND, BASICALLY ALLOWS ONE TO INDUCE YOUR CUSTOMERS OR THE END USERS TO MOVE TO ANOTHER SITE ON THE NETWORK.
THIS IS A PHISHING OR WHAT IS CALLED A PHARMING ATTACK.
IT GIVES PEOPLE POTENTIAL ECONOMIC BENEFIT.
THIS, IN FACT, CAN MOVE PEOPLE INTO ALTERNATIVE ROOT KINDS OF STRUCTURES OR INTO DIFFERENT NAMING SCHEMES THAT YOU REALLY DON'T KNOW ABOUT.
I APOLOGIZE FOR THE VERY BUSY SLIDE.
REMEMBER THAT ORIGINALLY THIS WAS DESIGNED FOR ENGINEERING PEOPLE.
AND SO THERE MAY BE A LITTLE BIT MORE DETAIL THAN YOU MIGHT WANT.
SO THERE IS A DOCUMENT CALLED RFC2833 WHICH IS A THREAT ANALYSIS OF THE DNS.
AND WE ACTUALLY LOOK AT SOME OF THIS UP HERE.
ONE OF THE PRIMARY FUNCTIONS IS PACKET INTERCEPTION.
IF YOU WANT TO STEAL THE PACKET.
YOU CAN PUT A PROCESS IN THE MIDDLE.
YOU CAN INTERCEPT DNS QUERIES ON ANY SORT OF SHARED NETWORK; RIGHT?
SO DOWN HERE, YOU CAN STEAL THESE QUERIES.
IF YOU'RE DOING A QUERY AND TRYING TO GET A -- AN ADDRESS FOR A DOMAIN NAME, IF I CAN STEAL IT THERE, WE'RE DOING, ON THAT ORIGINAL QUERY, WE'RE DOING WELL.
AND THAT'S WHAT WE'RE GOING TO DESCRIBE TODAY IS THAT PARTICULAR TYPE OF ATTACK.
YOU CAN DO THIS IN A VERY WHAT THEY CALL -- WHAT THE JAPANESE WOULD CALL EARNEST OR EASY AND EFFICIENT.
AND, IN FACT, IT'S REALLY QUITE EASY AND IT'S REALLY VERY EFFICIENT.
YOU CAN ALSO DO ID GUESSING AND QUERY PREDICTION, WHICH INJECT IN OTHER PLACES, UP HERE AT, SAY, 3 AND 4 AND 7 AND VARIOUS PLACES IN THE RESOLUTION HIERARCHY, YOU CAN INJECT THINGS THERE.
THAT'S A LITTLE HARDER.
YOU CAN NAME CHAIN BY POISONING THE CACHE.
YOU CAN HIJACK DNS SERVERS AND YOU LOOK AT SOME OF THIS STUFF MEASURING WHAT GOES ON IN THE SYSTEM.
WHAT GOES ON HERE IS THE ATTACK AS WE ARE GOING TO LOOK AT THE QUERY THAT YOU MAKE.
AND WE WILL INDUCE YOU TO GO SOMEWHERE ELSE.
WE WILL INJECT SOMETHING BEFORE THE OTHER DNS SERVERS CAN ACTUALLY RESPOND.
THIS IS A PROCESS IN THE MIDDLE ATTACK.
AND THERE ARE A NUMBER OF WAYS TO DO THIS.
ONE OF THEM REQUIRES INTERCEPTION OF THE PACKETS.
YOU CAN INTERCEPT IN A NUMBER OF DIFFERENT WAYS.
WE CAN DO A TCP DUMP.
WE CAN LOOK AT ALL THE PACKETS ON THE NETWORK.
GENERALLY, THIS IS A SHARED MEDIUM, A SHARED ETHERNET.
NOW, MOST PEOPLE THAT HAVE NETWORK, THE WIRES, THAT'S NOT REALLY SHARED.
THOSE ARE SWITCHED.
BUT WIRELESS IS A SHARED MEDIUM.
THOSE KIND OF HOT SPOTS ARE EVERYWHERE.
SO IT'S RELATIVELY EASY TO HOP INTO A SHARED MEDIUM AND DO THESE THINGS.
YOU CAN TAP IN AT THE ROUTER OR THE SWITCH, WHICH IS MUCH HARDER AND EASILY DETECTIBLE, OR CUT CABLES AND TAP. AND THAT IS DECIDEDLY VISIBLE TO PEOPLE.
SO IF YOU WANT TO BE INVISIBLE, YOU WANT TO BE ABLE TO GET ONTO A SHARED NETWORK.
WE THEN PARSE THE QUERY PACKET, LOOK FOR WHAT YOU'RE DOING.
WE GENERATE A FAKE ANSWER AND WRITE OUT TO THE NETWORK INTERFACE.
SO WE CAPTURE YOUR QUESTION, ANALYZE IT AND SEND BACK A RESPONSE BEFORE ANYONE ELSE CAN.
NOW, THE ATTACK TOOL THAT I'M GOING TO BE USING TODAY IS ONE OF SEVERAL.
THERE ARE LOTS OF THEM. AND THREE OF THEM ARE DESCRIBED HERE, WHICH IS ROUGHLY THE SAME TYPE OF CONSTRUCT.
THERE'S DNS HIJACK, THERE ARE VARIANTS OUT THERE ON THE NET.
LOTS OF PEOPLE CAN GET TO IT.
IT'S A LITTLE DIFFICULT TO USE.
USO 800D.
THAT WAS MY FIRST GRAD STUDENT. AND IT WAS PRIMARILY FOR LINUX.
HE HASN'T PORTED IT ANYWHERE ELSE.
BUT IT DOES WORK ON IPV6, FOR EXAMPLE. THIS PARTICULAR TOOL, IT'S 400 LINES OF C CODE.
IT'S VERY SMALL.
IT USES A COUPLE OF DIFFERENT THINGS IN THE OPERATING SYSTEM.
IT'LL RUN ON BSD-DERIVED SYSTEMS AND MACOS. AND SINCE I HAVE A MAC, I AM GOING TO RUN THE ATTACK FROM HERE.
NOW, WHEN WE ACTUALLY RAN THIS THE FIRST TIME, THIS WAS AT A WIDE PROJECT RESEARCH CAMP.
THERE WERE ABOUT 200 PEOPLE IN ATTENDANCE.
THESE ARE NETWORK ENGINEERS AND GRAD STUDENTS.
THESE ARE PEOPLE WHO KNOW BETTER.
WE TOLD THEM THAT IN ABOUT -- THERE WOULD BE A 15-MINUTE DNS ATTACK EXPERIMENT WITHOUT ANY NOTIFYING OF THE START TIME.
WE WERE JUST GOING TO RANDOMLY FIRE UP THE ATTACK IN 15-MINUTE INCREMENTS OVER THE COURSE OF A TWO-DAY PERIOD.
WE WOULD REDIRECT ANY DNS ADDRESS QUERY, WE WOULD SEND IT TO A SPECIFIED ADDRESS WHERE WE WOULD HAVE A WEB SERVER, AN SSH SERVER, AND SOME OTHER APPLICATIONS OF OUR CHOOSING.
AND THE ENVIRONMENT WE RAN THIS IN WAS A WIRELESS NETWORK THAT HAD AN 802.11A, 11B, WITH MULTIPLE CHANNELS AND WEP.
WE PUT THESE ON A PORTABLE PC.
AND ONE OF THE CONTESTS WAS TO FIND THE ATTACKING MACHINE.
THERE WAS ALSO -- IN THE EARLY STAGES, WE RECORDED ALL THE PACKETS.
IN THE TEST WE ARE DOING TODAY, IN THE DEMO WE ARE GOING TO RUN TODAY, WE WILL NOT TRACE OR TRAP ANY PACKETS.
SO THERE WILL BE NO RECORD OF THIS.
AND BOTH THE FUJIWARA AND SEKIYA ATTACK TOOLS WERE USED.
THE RESULTS OF THIS, IN THAT 15-MINUTE INCREMENT, WE FOUND 100 DIFFERENT IP ADDRESSES.
PEOPLE WERE LOOKING FOR 100 DIFFERENT SITES.
90% OF THEM WERE INDUCED TO GO TO OUR FAKE SITE.
WE DIDN'T GET 100% SUCCESS; BUT WE GOT -- 90% OF THEM WE WERE ABLE TO STEAL.
80% OF THE ANSWERS WERE INDUCED.
AND FROM A SOCIAL ENGINEERING PERSPECTIVE, THESE ARE PEOPLE WHO SHOULD KNOW BETTER.
THEY IGNORED THE SSH WARNING OF A HOST KEY CHANGE AND WENT AHEAD ANYWAY.
AND WE CAPTURED THEIR SSH KEYS AND THEIR PASSWORDS.
THE 10% THAT WE WERE UNABLE TO CAPTURE BOILED DOWN TO THESE FOUR ITEMS: THERE WAS A WIRELESS CHANNEL PROBLEM IN THAT THERE WERE MULTIPLE DIFFERENT BROADCAST DOMAINS AND WE ONLY WERE LOOKING IN A PARTICULAR BROADCAST DOMAIN.
SO WE DIDN'T GET THE ONES THAT WERE IN OTHER PLACES.
THERE WAS A REACHABILITY PROBLEM.
SOME PEOPLE WENT OUT OF THE REACH OF THE ATTACK DOMAIN THAT WE WERE IN.
SO THEY WERE SUCCESSFUL IN AVOIDING OUR ATTACKS.
THE OTHER THING IS IS THAT IF YOU HAVE ALREADY CACHED THE ANSWER, GETTING IT OFF OF YOUR DISK OR OUT OF MEMORY IS MUCH FASTER THAN US -- THAN HOW WE CAN RESPOND.
AND SO IF YOU'RE JUST USING THINGS YOU HAVE ALREADY LEARNED, IT BECOMES IMPOSSIBLE FOR US TO STEAL WITH THESE TOOLS.
AND THE TOOL AT THE TIME THAT WE USED DID NOT SUPPORT IPV6, AND THE JAPANESE ARE IPV6 -- THEY LIKE IPV6.
AND SO SOME PEOPLE ARE IPV6 NATIVE ONLY THAT. HAS BEEN FIXED IN THE CURRENT VERSION OF THE TOOL.
AND SO WE'LL GET THEM NEXT TIME.
SO THE VALIDITY OF THIS EMPIRICAL EXPERIMENT, IF WE LOOK AT THIS, YOU SAY, WELL, IF IT'S A SINGLE BROADCAST DOMAIN AND I'M IN A SWITCHED ENVIRONMENT, A VLAN TYPE ENVIRONMENT, I'M NOT VULNERABLE.
THE ANSWER IS, WELL, YES, YOU ARE.
BECAUSE WE CAN ATTACK THE SWITCH USING A THING CALLED ARP POISONING OR -- IN AN 802.11X ENVIRONMENT, WHICH IS BASICALLY A VPN-STYLE NETWORK, THERE IS NO SHARED KEY SO WE CAN'T INTERCEPT ALL OF THE PACKETS.
WE CAN GET SOME OF THEM.
IN A SHARED ENVIRONMENT LIKE A STANDARD 802.11B LIKE WE HAVE IN THIS ROOM, WE CAN ATTACK ALL THE PROTOCOLS.
SO SOME PEOPLE SAY, WELL, IF YOU'RE JUST GOING TO PROTECT THE DNS, WHAT'S THE POINT?
WELL, THE POINT IS THAT DNS FORGING GIVES US EFFICIENT WAY TO DO PHISHING OR PHARMING ATTACKS ON THE UNSUSPECTING USER BASE.
AND BECAUSE IT'S THE EASIEST WAY TO DO THIS, WE DON'T HAVE TO ATTACK THE OTHER PROTOCOLS; WE CAN GET PEOPLE TO DO WHAT WE WANT JUST BY USING A DNS ATTACK.
SO, WITH THAT DESCRIPTION, WE'RE GOING TO TRY AND RUN THE DEMONSTRATION HERE.
WE'RE GOING TO USE A SPECIAL NETWORK.
IF YOU WOULD LIKE TO PARTICIPATE, PLEASE SELECT THE WIRELESS NETWORK WITH THE SSID "BADBOY."
IF YOU DON'T LIKE THIS, LEAVE YOUR SSID AS "ICANN."
REGARDLESS, REFRAIN FROM ANY IMPORTANT COMMUNICATIONS HERE.
WE DO NOT WANT YOU TO THINK THAT WE ARE DOING BAD STUFF.
SO DON'T DO THINGS THAT YOU WOULD NOT LIKE TO GET CAPTURED.
SO I'M GOING TO START THE ATTACK PROGRAM AND THEN WE'RE GOING TO LOOK AT SOME OF THE THINGS THAT ARE GOING ON HERE.
AND THEN WE'LL ASK QUESTIONS.
SO, WE'RE GOING TO PUT THAT AWAY.
WE'RE GOING TO START THE ATTACK.
OKAY.
THE ATTACK'S RUNNING.
ANYBODY OUT THERE CHANGE THEIR SSID?
OKAY.
I WOULD PRESENT THE FOLLOWING.
I'M GOING TO TRY AN SSHN.
TO ONE OF MY HOSTS.
I HAVE SET UP THIS PARTICULAR HOST, AND I KNOW IT'S A LITTLE HARD TO READ.
BUT THERE'S THIS WARNING, IT SAYS "POSSIBLE DNS SPOOFING DETECTED."
AND IT GIVES ME ALL KINDS OF STUFF.
AND IT SAYS "I HAVE REQUESTED STRICT CHECKING."
AND SO IT WILL NOT LET ME LOG IN, AS A PRUDENT DEPLOYER OF THIS PARTICULAR SSH APPLICATION, THAT'S PROBABLY THE RIGHT THING TO DO, BUT A LOT OF PEOPLE DON'T DO THAT.
A LOT OF PEOPLE DO STUFF LIKE THIS, THEY'LL SSH IN.
THEY WILL NOT REQUEST STRICT CHECKING.
WHOOP.
I THINK I'VE ALREADY GOT THAT ONE OPEN.
UNLESS I HAVE LOST BADBOY AGAIN.
NOPE.
STILL THERE.
I STILL HAVE THAT CACHED.
I'M SORRY.
OKAY.
LET ME LOOK AT A WEB SITE, TRY AND FLUSH THE CACHE.
I'LL DO THAT IN A MINUTE.
I'M GOING TO GO TO A WEB SITE THAT I HAVE NOT GOTTEN IN MY CACHE.
HOW MANY PEOPLE HAVE TRIED TO GO TO A WEB SITE THAT IS NOT IN YOUR WEB CACHE?
DO YOU GET SOMETHING THAT LOOKS LIKE THIS?
OKAY.
WHAT THIS SAYS IS THAT YOU ARE FORGED.
THIS IS MY WEB SITE RESPONDING.
I HAVE INDUCED YOU TO COME TO MY WEB PAGE.
IT'S THE RIGHT DOMAIN NAME.
IT IS THE PROPER DOMAIN NAME.
IT SAYS WHAT I WENT TO IS I WANTED TO GO TO WWW.DISA.MIL.
THAT'S NOT A NORMAL PHISHING KIND OF ATTACK BECAUSE IT'S THE REAL DOMAIN NAME.
BUT I'VE STILL STOLEN IT.
IF I HAD TRIED TO HIDE OR PUT UP A FAKE-LOOKING WEB SITE, I COULD DO THAT RELATIVELY EASILY.
OKAY.
ARE YOU CONVINCED THAT THERE IS A LEGITIMATE PROBLEM WITH THIS KIND OF STUFF?
SO FAR, SO GOOD?
CAN I SHUT DOWN THE ATTACK?
OR SHOULD I LEAVE IT RUNNING?
SHOULD I MOVE THE ATTACK OVER TO THE ICANN NETWORK?
>> NO!
>>BILL MANNING: NO?
>> GOT A LOT MORE DAMAGE --
>>BILL MANNING: ALL RIGHT.
SO THE ATTACK IS OVER HERE.
LET'S GO BACK.
WHAT DO YOU THINK OF THIS?
DOES THIS SCARE YOU?
TO RESTORE YOURSELF, YOU CHANGE YOUR SSID BACK TO ICANN.
WE'RE GOING TO SHUT DOWN BADBOY SHORTLY AFTER THIS PARTICULAR SESSION.
IF YOU'RE IN WINDOWS XP, DO AN IP CONFIG, FLUSH THE DNS, AND THEN RESTART YOUR APPLICATIONS.
IN YOUR MACOS, YOU CAN DO A LOOKUP D.
AND WITH A FLASH CACHE AND FREE BSD, I DON'T THINK ANYBODY IS RUNNING FREE BSD HERE.
OH, IT'S FLUSH.
I'M SORRY.
THAT IS MY JAPANESE.
FLUSH.
SO THE ASSERTION THAT WE -- I COME AWAY WITH THIS IS THAT DNSSEC, IF IT'S DEPLOYED, MAY HELP IDENTIFY AND POSSIBLY HELP FOIL THESE TYPES OF ATTACKS.
THANK YOU VERY MUCH.

(APPLAUSE.)
>>BILL MANNING: WHO'S NEXT?

(APPLAUSE.)
>>FREDERICO NEVES: I HAVE INITIALLY FORGOTTEN TO TELL.
WE HAVE COPIES OF ALL THE PRESENTATIONS IN THE FRONT ON YOUR LEFT.
IF YOU WANT TO LOOK MORE CLOSELY TO -- YOU CAN GET THEM OUT THERE.
>>RUSS MUNDY: WELL, THIS WAS SUPPOSED TO WORK.
OKAY.
SO THE HANDY-DANDY TOOLS THAT COME WITH POWERPOINT AREN'T SO HANDY-DANDY AND WONDERFUL.
SO I'LL JUST DO THIS WITHOUT THEM.
OKAY.
AS IT SAYS UP ON THE SCREEN, I'M RUSS MUNDY FROM SPARTA.
AND I'M HERE TO GIVE, REALLY, THE TECHNICAL OVERVIEW OF WHAT WE HAVE IN THE DNSSEC DEPLOYMENT ACTIVITY.
BUT IT'S, IN GENERAL, A DNS OVERVIEW ALSO.
PLUG IN POWER, SINCE WE HAVE IT.
AND WE HAVE BEEN WORKING IN THE DNS AREA FOR A LARGE NUMBER OF YEARS -- AND THIS REALLY KIND OF GIVES FOLKS A CHANCE TO GO BACK AND GET A LITTLE INFORMATION ABOUT DNS ITSELF, AS WELL AS DNS SECURITY.
WE WANTED TO MAKE SURE THAT THERE WAS AT LEAST SOME COMMON BACKGROUND THAT FOLKS HAD IN TERMS OF DNS AND HOW IT WORKS, SOME OF THE FUNCTIONS AND MECHANICS OF WHAT GOES ON.
AND THE DNS ITSELF WAS CREATED IN THE MID-'80S AS A REPLACEMENT FOR A FILE CALLED HOST.TEXT THAT WAS DISTRIBUTED FROM A SINGLE LOCATION, PICKED UP EVERY NIGHT BY ALMOST EVERY HOST ON THE ARPANET, WHICH AT THAT TIME WAS IN THE HUNDREDS, NOT THOUSANDS, OR CERTAINLY NOT MILLIONS.
IT WAS THE FIRST SYSTEM OF NAME SERVICE THAT WAS EVER DEVELOPED THAT WAS FROM THE BEGINNING FOCUSED AT BEING A STANDARDS-BASED NAME SYSTEM.
IN OTHER WORDS, THE PLAN FROM THE VERY BEGINNING WAS THAT THERE COULD BE MULTIPLE PROVIDERS OF THE SOFTWARE AND OF THE ACTUAL USE OF AND IMPLEMENTATION OF VARIOUS PACKAGES THAT WOULD DO DNS.
BUT IT DIDN'T HAVE TO COME FROM A SINGLE SOURCE.
WHICH FOLKS THAT HAVE BEEN AROUND NETWORKING FOR A WHILE WILL THINK BACK, AND THEY WILL REMEMBER HOW THINGS LIKE NOVELL AND SO FORTH HAD THEIR OWN PARTICULAR UNIQUE, AND EACH ONE WAS PROPRIETARY TO BEGIN WITH.
BUT DNS FROM THE BEGINNING WAS STANDARDS-BASED, AND CONTINUES TO BE THAT WAY.
THERE WASN'T ANY ATTEMPT IN THE BEGINNING TO IDENTIFY SECURITY REQUIREMENTS FOR DNS, AND, QUITE FRANKLY, IN THE MID-'80S, BESIDES THE WORLD FROM A NETWORK PERSPECTIVE BEING DRAMATICALLY DIFFERENT, WE HAD NO IDEA WHAT SECURITY REALLY MEANT WHEN IT CAME TO A NAME SYSTEM IN THE MID-'80S.
WELL, QUICKLY, AFTER IT GOT OUT THERE, IT REALLY IS NOW AND HAS CONTINUED -- HAS BEEN FOR A LONG TIME A CRITICAL PART OF THE BACKBONE INFRASTRUCTURE OF THE NETWORK INFRASTRUCTURE ITSELF.
OKAY.
SO WHAT IS IT?
IT'S REALLY WHAT'S USED BY EVERY USER AND APPLICATION THAT WANTS TO LOOK UP SOMETHING ON THE INTERNET BASED ON A NAME.
AND SO THE USERS, AS HUMANS, ARE MUCH MORE COMFORTABLE LOOKING UP NAMES THAN NUMBERS.
IT PRIMARILY IS USED FOR LOOKING UP NETWORK NUMBERS.
BUT THERE ARE A NUMBER OF OTHER THINGS THAT ARE CONTAINED WITHIN THE DNS, PROBABLY MOST COMMON IS THE IDENTIFICATION OF MAIL SERVERS FOR PARTICULAR DOMAINS.
SO THERE'S A SPECIFIC WAY IN WHICH YOU LOOK UP -- SOFTWARE LOOKS UP THE NAME AND IP ADDRESS FOR A MAIL SERVICE FOR DOMAINS.
WELL, IT'S GLOBALLY DISTRIBUTED, LOOSELY COHERENT, VERY, VERY SCALABLE.
IT'S GROWN DRAMATICALLY OVER THE YEARS.
AND VERY RELIABLE.
THERE'S TWO PRIMARY TYPES OF COMPONENTS THAT MAKE UP DNS.
ONE COMPONENT IS THE INFORMATION ITSELF.
AND THAT'S SOMETIMES REFERRED TO AS THE NAME SPACE.
AND THAT'S REALLY KIND OF THE DATA OR THE CONTENTS.
THAT'S WHAT'S INSIDE OF THE NAME SYSTEM.
THE MOVING PARTS, AS I'M CALLING THEM HERE, ARE THOSE PIECES, AND MOSTLY SOFTWARE AND RUNNING ON HARDWARE, THAT SERVE OUT OR REQUEST THE INFORMATION AND GET ANSWERS FROM THE SERVERS.
SO THE END USERS USE WHAT ARE CALLED RESOLVERS OR CLIENTS ON THEIR END MACHINES.
AND AS EVERYONE WAS PLAYING WITH THE DEMO LAST TIME AND I WAS SITTING OUT THERE, AND I GOT MY DNS SPOOF, TOO, LIKE EVERYBODY ELSE THAT TRIED IT, YOU'RE USING A CLIENT OR A RESOLVER TO GO GET INFORMATION OUT OF THE DNS SERVER -- SYSTEM.
AND THE SERVERS THEMSELVES ARE THOSE DEVICES THAT ACTUALLY PROVIDE THE INFORMATION.
SO HERE'S A PICTURE OF THE INFORMATION THAT'S -- I FEEL IS VERY STRANGE STANDING HERE, BECAUSE I THINK I'M RIGHT IN FRONT OF THE SCREEN.
SO IF ANYONE WANTS ME TO MOVE, YOU KNOW, JUST WAVE YOUR HAND OR SOMETHING, AND I'LL JUST SHIFT AROUND TO BE SURE YOU CAN SEE.
BUT THE HIERARCHY OF THE INFORMATION IS USUALLY DRAWN VISUALLY AS A ROOT.
YOU CAN'T, YOU KNOW -- YOU DON'T NORMALLY SEE THIS AS IT'S OUT IN THE REAL WORLD.
BUT IT IS STACKED UP IN AN INVERSE TREE KIND OF THING.
AND YOU'LL SEE A LOT OF EXAMPLES THROUGH HERE OF WWW.DARPA.MIL.
THIS WAS A NAME, AN IP ADDRESS I'VE USED BEFORE AS A GOOD EXAMPLE THAT A LOT OF PEOPLE HAVE HEARD OF DARPA, ARE FAMILIAR WITH THEM.
AND THEIR WEB SITE IS USUALLY INTERESTING TO LOOK AT.
THE OTHER THINGS BESIDES THE ACTUAL REVERSE MAPPING, THERE'S A COUPLE OF PRINCIPLES THAT HAVE BEEN INVOLVED IN THE NAME SPACE THAT'S VERY IMPORTANT.
ONE IS THAT THE OWNERS OF THE PARTICULAR -- EACH PARTICULAR DOT ON THIS NAME SPACE ARE -- HAVE THE RESPONSIBILITY AND AUTHORITY FOR, ESSENTIALLY, THE TOTAL CONTENT OF EACH OF THOSE PLACES.
AND SO THE OPERATION ITSELF IS ALSO EXTREMELY DISTRIBUTED.
SO THE NAME CONTENT, THE NAME SPACE, IS DISTRIBUTED THROUGHOUT THE INTERNET BY ANYONE WHO OPERATES -- ACTUALLY OPERATES A ZONE.
AND THERE'S VERY -- THERE'S AN AMOUNT OF COORDINATION BETWEEN THE PEOPLE THAT ARE OPERATING AT DIFFERENT PARTS OF THE HIERARCHY, BETWEEN WHAT ARE OFTEN REFERRED TO AS A PARENT AND CHILD, IN THIS CASE, YOU CAN LOOK AT THE MIL DOT UP THERE, AND THEN THE DARPA UNDERNEATH OF IT.
AND THAT'S A PARENT AND CHILD TYPE OF RELATIONSHIP.
DO WE HAVE A LASER POINTER?
IF WE DON'T, IT'S OKAY.
IT MIGHT BE HANDY IF SOMEONE DOES HAVE ONE AND CAN MAKE USE OF.
HERE'S ANOTHER PICTURE OF A MORE COMPLEX DNS TREE.
AND THERE ARE SOME VERY LARGE, VERY COMPLEX MIXTURES THAT OCCUR OUT THERE.
GOOD.
AND ONE THING THAT I WANT TO POINT OUT HERE IS, ACCORDING TO THE DEFINITIONS FROM THE SPECS, THE GREEN BLOB IN HERE THAT INVOLVES SPACES THAT ARE UNDERNEATH A PARTICULAR PART OF THE TREE, THIS IS TECHNICALLY A DOMAIN.
AND WITHIN THAT DOMAIN IS A ZONE.
AND THAT'S HOW I WILL TRY TO CONSISTENTLY USE THE TERMS THROUGHOUT THIS PRESENTATION.
I DON'T GUARANTEE I'LL BE 100% CORRECT.
BUT ONE OF THE THINGS THAT HAS OCCURRED OVER TIME AND THAT THE WORLD RELATED TO DNS, PEOPLE TEND TO BE NOT REAL PRECISE WHEN THEY USE THE TERM "ZONE" OR THEY USE THE TERM "DOMAIN," AND SO IT SOMETIMES DOES GET VERY CONFUSING.
BUT I WILL TRY HARD TO USE THOSE CONSISTENTLY HERE.
SO WE HAVE AN END USER WHO WANTS TO DO A LOOKUP.
AND THEY HAVE NORMAL A NAME SERVER SITTING CLOSE BESIDE THEM.
WHEN THEY WANT TO DO THE LOOKUP, IT GOES FIRST TO THE ROOT NAME SERVER, GIVEN THAT THERE'S NO INFORMATION IN THE LOCAL SERVER TO ANSWER THE QUESTION, GOES TO THE ROOT NAME SERVER, AND THE ROOT NAME SERVER TELLS IT HOW TO GET TO A TOP-LEVEL DOMAIN SERVER THAT'S APPROPRIATE AND THAT TELLS IT HOW TO GET TO WHATEVER THE RIGHT ZONE SERVER IS.
AND THERE CAN BE INTERMEDIATE ZONES FROM BACK IN THE PREVIOUS PICTURE, THERE'S A WHOLE HIERARCHY.
YOU CAN END UP WALKING DOWN THROUGH A LOT OF SERVERS.
ONCE THAT INFORMATION IS IN THE LOCAL SERVER, THEN THE ANSWER IS SENT BACK TO THE END USER WHO ASKED THE QUESTION IN THE FIRST PLACE.
THERE'S -- THE INFORMATION THAT'S OUT IN THOSE SERVERS HAS TO BE PLACED THERE IN SOME MANNER.
AND THIS PARTICULAR SLIDE DESCRIBES HOW THE INFORMATION GETS INTO THE NAME SERVERS.
THERE'S NORMALLY, FOR A ZONE, SOMEPLACE WHERE THERE IS DATA PREPARATION, OFTEN A ZONE DATABASE THAT'S RUNNING ON A SEPARATE MACHINE.
THAT PREPARES A FILE THAT IS PUT INTO THE MASTER SERVER FOR THE ZONE.
AND THAT ZONES MASTER SERVER WILL TRANSFER THE INFORMATION THAT IT HAS TO OTHER SERVERS THAT ARE SUPPORTING THAT ZONE.
THEY'RE CALLED SECONDARY SERVERS FOR THE ZONE.
THERE'S ALSO A WAY OF GETTING DATA IN AND CHANGE CALLED DYNAMIC UPDATE.
BUT I WON'T TALK ANY FURTHER ABOUT THAT.
IT'S JUST PROVIDED FOR COMPLETION'S SAKE HERE.
AND SO THE INFORMATION IS INTO THE ZONE, AND AGAIN THE USER SENDS OUT THE QUERY TO HIS LOCAL SERVER, THE LOCAL SERVER GOES TO ANY ONE OF THE NAME SERVERS, GETS THE INFORMATION IT NEEDS AND THEN COMES BACK TO IT. AND SO IT'S REALLY VERY MUCH A QUERY RESPONSE. DATA GETS PUT INTO THE SYSTEM AND DATA GETS BROUGHT OUT OF THE SYSTEM.
SO WHY DO WE WORRY ABOUT DNS SECURITY? BILL GAVE A VERY GOOD DEMONSTRATION, AND ESPECIALLY THOSE FOLKS WHO CHANGED THEIR SSID HAVE A GOOD INDICATION OF EXACTLY WHAT YOU CAN DO HERE.
AND IN FACT, WHEN FORGED DATA GETS PUT IN PLACE, IT REALLY BREAKS MOST APPLICATIONS IN ONE WAY OR ANOTHER.
YOU CAN TRULY REPLACE A WEB SITE WITHOUT EVER TOUCHING THE VICTIM'S WEB SITE ITSELF.
WE HAVE A DIFFERENT DEMO THAT WE'VE PUT TOGETHER, MY ORGANIZATION, BUT WE DIDN'T BRING IT THIS TIME. IT TAKES A FEW MORE MACHINES, SO WE ELECTED TO GO WITH THIS ONE THAT BILL DID, WHERE YOU LITERALLY CAN REPLACE THE CONTENT OF A WEB SITE ON THE FLY, WITHOUT THE VICTIM WEB SITE EVEN KNOWING IT'S HAPPENING.
AND THE CLIENT IN THAT CASE THAT'S BEING SPOOFED, MORE THAN LIKELY WON'T KNOW IT'S HAPPENING EITHER.
E-MAIL ROUTED TO LOCATIONS CAN BE REROUTED THROUGH PEOPLE WHERE THEY CAN'T GET AHOLD OF IT, MAKE A COPY, DELIVER IT TO WHERE IT WANTS TO GO AND YOU'D NEVER KNOW IT. BILL SHOWED THE MAN-IN-THE-MIDDLE ATTACK. AND THERE IS THERE'S DNS ATTACK AND MAN-IN-THE-MIDDLE ATTACK IS A VERY GOOD EXAMPLE OF A PRECURSOR TO ANOTHER ATTACK, SSH OR WEB SERVER TYPE ATTACK.
TOOL KITS ARE READILY AVAILABLE AND THEY ARE, INDEED, OUT ON THE INTERNET. AND EVERY ELEMENT OF THE HIERARCHY ITSELF IS VULNERABLE TO ATTACK. THAT DOESN'T MEAN THE ATTACK WOULD BE SUCCESSFUL BUT ANYPLACE IN THE NAME SYSTEM YOU CAN WAGE AN ATTACK.
WHEN YOU GO TO PUT SECURITY, SUCH AS DNS SECURITY, INTO THE ACTUAL RUNNING INFRASTRUCTURE, YOU HAVE SOME CHALLENGES THAT ARE QUITE IMPORTANT TO CONSIDER.
ONE IS BACKWARD COMPATIBILITY. YOU CAN'T BREAK EXISTING OLDER SOFTWARE WHEN YOU PUT THE NEW SOFTWARE AND THE NEW CAPABILITIES IN PLACE.
AND ONE OF THE OTHER DIFFICULTIES, PARTICULARLY WITH DNS, IS IF THERE IS A DNS FAILURE AS PART OF YOUR DEPLOYMENT OR GETTING IT OUT THERE, APPLICATIONS OFTEN HAVE NO ALTERNATIVES EVEN THOUGH MANY CAN USE IP ADDRESSES INSTEAD OF NAMES, THE REALITY IS MOST DON'T AND MOST DON'T KNOW WHAT THE IP ADDRESS IS THAT THEY SHOULD BE USING.
AND IN FACT WHEN END USERS AND APPLICATIONS ARE HAVING A PROBLEM WITH THEIR DNS SERVICE AND IT'S NOT WORKING CORRECTLY, TO THEM THE INTERNET'S DOWN. FROM A FUNCTIONAL PERSPECTIVE, THEY CAN'T DO WHAT THEY NEED TO DO ON THE INTERNET SO FOR THEM THE INTERNET IS DONE.
SOME OF THE OTHER MOTIVATORS. ANT?
>>: I SPAM, ANTI PHISHING TECHNOLOGIES WHICH ARE TRYING TO STOP THE SPAM AND PHISHING BASED ON ORDINARY DNS. THE PEOPLE MAKING MONEY OFF OF SPAM AND PHISHING WILL BE ATTACKING THE DNS. THE PREVENTION TECHNOLOGIES BY WAY OF ATTACKING THE DNS FOR THOSE USING THAT. STOCK TICKERS, YOU CAN CHANGE ON THE FLY VALUES THAT GET PRINTED OUT ON CLIENT'S WEB SERVERS ABOUT WHAT'S THE VALUE OF IBM AND HOW IS IT DOING TODAY. PEOPLE MAKE MONEY FROM DOING THINGS LIKE THAT AND OTHER DECEPTIVE THINGS. AND ENUM AS IT GROWS, THE IMPORTANCE OF ACCURACY AND PRECISELY CORRECT INFORMATION IS IMPORTANT AND MORE SO AS WE GET THERE.
NOW, A LITTLE -- A DIFFERENT ILLUSTRATION OF THE ATTACK ITSELF THAN WHAT BILL SHOWED EARLIER.
HERE WE HAVE A DARPA.MIL REQUEST AGAIN FROM BILL'S LAPTOP ON THE LEFT OF THE SCREEN UP HERE. AND HE'S SENDING OUT AN EASY-TO-OBSERVE UDP PACKET AND RUSS'S LAPTOP IS SITTING HERE OBSERVING IT. AND SO IT SEES THE REQUEST AND LITERALLY FORGES AN ANSWER THAT GO BACK TO THE REQUESTER, MORE OR LESS IN REAL TIME FROM WHEN HE ASKED THE QUESTION.
IN THE MEANTIME, THE LOCAL SERVER IS GOING OUT TO QUERY THE ROOT SERVER, THE MILL SERVER THE DARPA.MIL SERVE AND GETS AN ANSWER BACK. HOWEVER, THE PROBLEM IS THE WAY THE END-USER CLIENTS WORK TODAY IS THEY TAKE THE FIRST ANSWER THEY GET AND IF IT HAPPENS TO BE THE SPOOFED ANSWER, THAT'S WHAT YOU'RE GOING TO GET ON YOUR CLIENT'S SOFTWARE ON YOUR END MACHINE. AND YOU WILL, IN EVERY INSTANCE TODAY WITH CLIENT SOFTWARE, TAKE THE WRONG ANSWER IF YOU GET THE WRONG ANSWER FIRST.
OKAY. SO WHAT DOES IT DO? IT REALLY PROVIDES THE ADDITION OF DATA INTO THE DNS SYSTEM THAT LETS END USERS VALIDATE THE AUTHENTICITY OF THE SOURCE OF THE DATA THAT THEY RECEIVE FROM A DNS QUERY AND VALIDATE THE INTEGRITY OF THE DATA CONTENT ITSELF.
IN OTHER WORDS, IT CAME FROM THE RIGHT PLACE AND IT IS THE RIGHT STUFF THAT YOU'RE SUPPOSED TO BE GETTING FROM THAT PLACE.
IT INTEGRATES WITH THE EXISTING INFRASTRUCTURE, OBSERVERS AND CLIENTS, AND DOES SO IN A MANNER THAT'S SUPPORTING A GRADUAL MIGRATION OF THE CAPABILITY INTO THE DNS.
YOU'LL GET, MORE THAN LIKELY, THE GREATEST BENEFIT WHEN WE GET TO THE POINT WHERE APPLICATIONS THEMSELVES ARE ABLE TO UNDERSTAND IF THE DNS INFORMATION IS VALIDATED.
I'VE BEEN SHOWING IN THE ILLUSTRATIONS ON THE END MACHINE BUT IT CAN ACTUALLY BE DONE ON THE LOCAL SERVER AND PROBABLY WILL BE IN A NUMBER OF PLACES BEFORE WE GET THAT.
NOW, A LOT OF PEOPLE SAY, ISN'T SSL ALL THAT'S NEEDED FOR SUCH A THING? WELL, SSL ISN'T REALLY A MAGIC BULLET. NEITHER IS DNSSEC, FOR THAT MATTER, THAT'S FOR SURE, BUT THEY BOTH PROVIDE A GOOD AMOUNT OF SECURITY IN THEIR OWN RESPECTIVE WAYS. ONE OF THE THINGS ABOUT SSL IS IT'S NEVER GOING TO BE USED UNIVERSALLY. THERE WILL BE A LOT OF PLACES SSL WON'T BE USED. SO IF YOU'RE DEPENDING ON THAT YOU'RE ALREADY IN A SITUATION WHERE THAT WON'T SOLVE YOUR PROBLEM.
THERE IS A USAGE PROBLEM, AGAIN, THOUGH, WITH THE USER INTERFACE PORTION. THERE'S A LOT OF SECURITY ALERTS THAT HAPPEN, THEY COME UP ALL THE TIME, AND USERS WILL MANY TIMES, IF NOT MOST OF THE TIME, SAY, OH, WELL, FINE, I'LL ACCEPT THAT. JUST GO ON.
THEY'RE SURPRISED, NOT ANNOYED
THE TECHNOLOGY ITSELF IS NOT A PROBLEM. IT'S HOW IT'S INTERFACED TO THE USER AND USED BY THE USERS.
HERE'S A FEW EXAMPLES. SO IF YOU GET A COMMON NAME MISMATCH IN THE CERTIFICATE, SO YOU'RE TRYING TO GET TO ROBOCO DIRECT AND YOU THINK THAT OUGHT TO BE THE NAME OF THE WEB SITE, WELL, BOY, THIS RESOLUTION IS NOT VERY GOOD. ALL I CAN SAY IS PLEASE LOOK AT THE PACKETS THAT YOU CAN ACTUALLY READ THE LETTERS THERE.
BEING A GOOD SECURITY CONSCIENTIOUS PERSON I SAY SHOW ME THE CERTIFICATE AND YOU SEE IN THE CERTIFICATE, I'M GOING TO STEP OUT OF THE WAY HERE, THAT THE NAME THAT CAME IN WAS DIFFERENT THAN THE NAME THAT WAS IN THE COMMON NAME OF THE CERTIFICATE.
OKAY. SO IN THIS CASE YOU'VE GOT A MISMATCH OF THE COMMON NAME.
AS A USER, HOW DO YOU KNOW? SHOULD YOU ACCEPT IT? SHOULD YOU SAY NO? ARE YOU GOING TO GO TO THAT SITE? WHAT ARE YOU GOING TO DO? WELL, MOST PEOPLE SAY, OKAY, I'M JUST GOING TO GO TO THAT SITE.
ANOTHER SIMILAR EXAMPLE IS WITH THE CERTIFICATE AUTHORITY. THE OLAF KOLKMAN WHO IS THE GENTLEMAN WHO PREPARED THIS SET OF SLIDES EXTRACTED FROM ANOTHER PRESENTATION, HE HAS A TRAVELING COMPANION NAMED BURT, AND THOSE THAT HAVE MET OLAF KNOWS BURT IS THIS CUTE LITTLE CHARACTER FROM A TELEVISION SHOW CALLED SESAME STREET AND THERE'S A LOT OF THINGS INCLUDING BURT'S CERTIFICATE AUTHORITY HERE. SO IS BURT'S CERTIFICATE AUTHORITY HERE? IS THAT A LEGITIMATE CERTIFICATE AUTHORITY? AGAIN, YOU DON'T KNOW IF IT'S NOT ALREADY A TRUSTED CERTIFICATE AUTHORITY.
SO YOU GET ALL THESE MESSAGES, VERY FREQUENTLY, AND MOST OF THE TIME PEOPLE JUST CLICK RIGHT THROUGH AND SAY I'M GOING TO DO THAT. AND AT THE END, ARE YOU SECURE OR HAVE YOU BEEN SUBVERTED? AND THE REAL ANSWER IS YOU DON'T KNOW.
NOW, HOW DOES DNSSEC HELP THIS PICTURE? OKAY. SINCE REMEMBERING DNSSEC SECURES THE MAPPING BETWEEN THE NAME OR THE HUMAN READABLE DOMAIN NAME AND AN IP ADDRESS. AND THIS ALL OCCURS PRIOR TO WHEN THE CERTIFICATES EVEN SHOW UP.
AND SO ONCE YOU GET TO A PLACE AND YOU'RE USING DNS SECURITY ASSOCIATED WITH IT THAT YOU'VE GOT A HIGH CONFIDENCE LEVEL THAT THE ACTUAL IP ADDRESS FOR THE PLACE THAT YOU WERE GOING TO IS, IN FACT, A MATCH WITH THE NAME THAT'S IN THE NAME SYSTEM, AND THAT IT WAS PUT IN THERE BY THE LEGITIMATE PEOPLE FOR THAT NAME SYSTEM.
ONE OTHER THING THAT IS IMPORTANT HERE TO POINT OUT IS THAT THE WAY THAT THE WORLD OPERATES TODAY, MOST OF THE WEB SERVICE HTTP AND THE SECURITY MECHANISMS THERE ARE OPERATED COMPLETELY INDEPENDENTLY AND SEPARATELY FROM NAME SERVERS AND DNS SECURITY.
SO YOU'LL HAVE SOMEWHAT A SEPARATE PARALLEL CHECK AS TO THE CONFIDENCE OF THE INFORMATION YOU'RE GETTING.
THERE'S A POINTER HERE ALSO TO AN ARTICLE THAT WAS PUBLISHED RECENTLY BY THE ACM THAT IF FOLKS WANT TO TAKE A LOOK AT IT, IT GIVES AN IDEA OF SOME OF THE EXPECTED COMING ATTACKS ON THE CERTIFICATE SYSTEMS.
SO IT ALSO IS -- DNS SECURITY GOES BEYOND THE SSL AREA AND FOR OTHER ATTACKS, SUCH AS THE ONE ON SSH THAT BILL DEMOED EARLIER.
THERE ARE A FEW MORE VULNERABILITIES THAT I WANTED TO MENTION HERE, PLACES DNS COULD BE ATTACKED BESIDES JUST THAT LAST LINK BETWEEN THE END USER AND THE LOCAL SERVER.
SO WHEN THEY USER SENDS OUT THE QUERY, GETS THE ANSWER, AND YOU CAN SEE THERE THAT GETTING THE ANSWER OF 128.9.128.127.
IN THE MEANTIME, ANY OF THESE OTHER PLACES OUT HERE, FORGED DATA, CACHE POISONING, OTHER MAN-IN-THE-MIDDLE TYPES OF ATTACKS, COULD HAVE WITH THE REGULAR DNS COULD HAVE PROVIDED THAT INFORMATION AND YOU DON'T KNOW IF IT'S RIGHT OR WRONG AND IN THIS CASE IT'S WRONG BECAUSE SOMEONE PROVIDED THE INCORRECT INFORMATION THAT CAUSED THE END USER CLIENT TO A DIFFERENT PLACE, IN THIS CASE ANOTHER INSTANTIATION OF DARPA.MIL.
SO WHEN YOU GO THROUGH THIS PROCESS WITH DNS SECURITY IN PLACE, YOU GET THE SIGNED AND VALIDATABLE INFORMATION OUT OF THE NAME SYSTEM, OUT OF THE DNS, THAT ENABLES THE END USER TO ACTUALLY VERIFY THE INFORMATION THAT IT RECEIVES.
SO IN THIS CASE, IT DOESN'T MATTER WHETHER OR NOT THE ATTACKERS ATTACKED BEFOREHAND, BECAUSE THEIR INFORMATION WOULD NOT VALIDATE WITH THE SIGNATURE INFORMATION THAT IS AVAILABLE TO THE END USER FOR VALIDATION.
SO A REAL QUICK HYPERSUMMARY, IS A QUICK NAME FOR IT, WHAT IS DNS SECURITY, HOW DOES IT WORK, WHAT'S GOING TO NEED FOR IT TO HAPPEN TO GET OUT THERE. EACH ZONE THAT NEEDS TO USE DNS SECURITY WILL SIGN ITS OWN DATA WITH THEIR PRIVATE KEY AND THE SIGNING SHOULD PROBABLY BE DONE MOST EFFECTIVELY AT THE TIME THE DATA IS GENERATED AT A MACHINE OTHER THAN ON THE WIRE NAME SERVER BECAUSE MOST OPERATIONS GENERATE THE DATA SEPARATELY IN SOME DATABASE OR STRUCTURE.
WHEN THE USER SENDS OUT A QUERY, THEY WILL GET BACK THE INFORMATION THEY ASKED FOR, IF YOU WILL, THE NORMAL DNS INFORMATION, PLUS THEY'LL ALSO GET DNSSEC DATA THAT IS ASSOCIATED WITH THAT INFORMATION COMING OUT OF THE DNS. AND THE WAY THAT THE DNS SECURITY DESIGN IS STRUCTURED, YOU GET THE INFORMATION TOGETHER AND IT'S JUST A LARGER ANSWER RATHER THAN WHAT YOU WERE GETTING BEFORE.
THE USERS THEN ARE ABLE TO AUTHENTICATE THE INFORMATION THAT THEY GET BACK. EACH CLIENT WOULD NEED TO HAVE ONE TRUSTED KEY TO BEGIN WITH AND FROM THERE, IDEALLY THAT TRUSTED KEY WOULD BE FROM THE (INAUDIBLE) YOU COULD GO DOWN THE HIERARCHY, BUT YOU COULD ALSO DO IT, FOR INSTANCE, FROM THE DOT MIL ZONE, IF YOU WERE IN THERE, YOU WOULD VALIDATE FROM THAT POINT ON DOWN.
SO IT SHOWS YOU GET THE VALIDATED SOURCE AUTHENTICITY AND INTEGRITY.
THE OTHER IMPORTANT THING IS THE ENABLING OF OTHER SECURITY TECHNOLOGIES AND THE ENABLING OF THE PEOPLE TO -- THAT WANT TO MAKE USE OF DNS FOR DOING VARIOUS ACTIVITIES, ALLOWS THEM TO BUILD ON A FIRM BASIS OF DATA THAT THEY'RE GETTING OUT OF THE DNS, WHERE TODAY YOU GET DATA AS LONG AS -- YOU GET THE RIGHT DATA AS LONG AS PEOPLE AREN'T ATTACKING AND TRYING TO CHANGE IT IN GENERAL. SO IT WORKS WITH OTHER SECURITY OF TECHNOLOGY AND DATA USES.
SO THAT'S THE END OF MY PRESENTATION. I THINK WE'RE A LITTLE BIT BEHIND ON WHAT OUR TIME SCHEDULE IS.
LET ME ASK FREDERICO IF WE WANT TO DO ANY QUESTIONS AS WE GO OR IF WE WANT TO WAIT.
OKAY. SO WE HAVE A FAIR HUNK OF TIME AT THE END FOR QUESTIONS, SO PLEASE JOT THEM DOWN, IF YOU HAVE SOME OR REMEMBER THEM, AND WE CAN GO OVER THEM LATER.
THANK YOU.
(APPLAUSE).
>>DOUG BARTON:GOOD MORNING. CAN EVERYBODY HEAR ME OKAY?
>>>: NO.
>>DOUG BARTON: I'M SORRY. OKAY. IS THAT BETTER? FABULOUS.
GOOD MORNING, AND ONCE AGAIN, THANK YOU FOR ATTENDING THIS VERY IMPORTANT SESSION AND COMING TO LEARN MORE ABOUT THIS INCREDIBLY IMPORTANT TOPIC FOR THE FUTURE OF THE NETWORK.
MY NAME IS DOUG BARTON, FOR THOSE OF YOU WHO DON'T KNOW I'M THE GENERAL MANAGER OF IANA, AND A MEMBER OF THE ICANN STAFF, AND I WILL BE MODERATING THE PANEL THIS MORNING.
AND IF WE COULD START QUICKLY BY HAVING EACH OF THE MEMBERS INTRODUCE THEMSELVES AND INDICATE THEIR AREA OF INTEREST IN THIS TOPIC. AND THEN I BELIEVE WE HAVE SOME PRESENTATIONS AS WELL.
>>RAM MOHAN: THANK YOU, DOUG. THIS IS RAM MOHAN, I'M THE CTO OF AFILIAS AND WE RUN THE DOT INFO REGISTRY AND WE PROVIDE REGISTRY SERVICES FOR .ORG.
>>FREDERICO NEVES: MY NAME IS FREDERICO NEVES FROM .BR.
>>>: ED LEWIS, I WORK FOR .BIZ.
>>JOHAN IHREN: JOHAN IHREN, PROXY FOR THE SWEDISH REGISTRY, AND DOING LOTS OF OTHER DNS SERVICES.
>>DOUG BARTON: FABULOUS. THANK YOU.
AND DO WE HAVE -- DO ANY OF YOU GUYS HAVE ACTUAL PRESENTATIONS PUT TOGETHER? I THOUGHT SO. I APOLOGIZE FOR A LITTLE BIT OF CONFUSION. WE SORTED THINGS OUT AT THE LAST MINUTE A BIT.
WE WOULD LIKE TO BEGIN -- OH, EXCELLENT. FABULOUS.
AS WE'VE DISCUSSED PREVIOUSLY AND AS RUSS'S EXCELLENT ILLUSTRATIONS INDICATED, THERE ARE VARIOUS LEVELS OF THE DNS HIERARCHY THAT ARE IMPORTANT TO KEEP IN MIND WHEN WE ARE DISCUSSING DNSSEC. AND ONE OF THE INTERESTING ASPECTS OF THIS PROTOCOL IS THAT IT ALLOWS YOU TO DEFINE WHAT WE'VE REFERRED TO AS ISLANDS OF TRUST, WHERE INDIVIDUAL ZONES OR INDIVIDUAL DOMAINS CAN HAVE DNSSEC SIGNATURES APPLIED TO THEM, AND IF YOU ARE INTERESTED IN SECURITY FOR THAT PARTICULAR DOMAIN, YOU CAN CONFIGURE THOSE KEYS INTO YOUR LOCAL RESOLVING NAME SERVER AND BE ABLE TO SECURELY IDENTIFY THE ANSWERS THAT COME BACK FROM THOSE INDIVIDUAL DOMAINS. AND THAT SYSTEM WORKS, AND IT'S VERY NICE FOR THOSE WHO, IN THE EARLY STAGES OF DNSSEC ARE INTERESTED IN HAVING SECURITY RELATED TO A SPECIFIC ZONE.
HOWEVER, IN THE LONG TERM, AS I'M SURE YOU CAN IMAGINE, MOST OF US VISIT TENS OR SOMETIMES EVEN HUNDREDS OR THOUSANDS OF DOMAINS IN A GIVEN DAY WHEN YOU TAKE INTO CONSIDERATION E-MAIL AND WORLD WIDE WEB AND OTHER ELEMENTS OF JUST DAY-TO-DAY NETWORK TRAFFIC. AND CONFIGURING INDIVIDUAL KEYS FOR EACH OF THOSE DOMAINS IS SIMPLY NOT A PRACTICAL MATTER, AND WOULD ACTUALLY PREVENT THE LONG-TERM ADOPTION OF DNSSEC BY THE MAJORITY OF THE USERS OF THE NETWORK.
AND FOR THAT REASON, THE ULTIMATE DESIGN OF THE PROTOCOL INCLUDES NOT ONLY THE ABILITY TO CHASE DNS ANSWERS UP THE TREE AND DOWN AS NEEDED, BUT ALSO THE DNSSEC KEYS THEMSELVES. AND THE ULTIMATE PART OF THIS SOLUTION IS FOR THE ROOT ZONE ITSELF TO BE SIGNED.
AND IF I COULD JUST ELABORATE BRIEFLY ON RUSS'S PRESENTATION, THE ROOT ZONE, UNLIKE THE OTHER DOMAINS -- SORRY? SPEAK CLOSER TO THE MIKE. OKAY. THANK YOU.
SORRY.
I HEAR A LOT OF ECHOING FROM MY STANDPOINT, SO I'M TRYING NOT TO BLOW OUT EVERYBODY'S EARDRUMS HERE.
THE ROOT ZONE, RATHER THAN CONTAINING INFORMATION ABOUT INDIVIDUAL DOMAINS, CONTAINS INFORMATION FOR EACH OF THE TOP-LEVEL DOMAINS THEMSELVES SO BY SIGNING THE ROOT ZONE IT ALLOWS ONE SINGLE SECURE ENTRY POINT INTO THE DNSSEC HIERARCHY WHICH WILL MAKE IT MUCH EASIER FOR ALL THE OTHER DOMAINS, EITHER THE TOP-LEVEL DOMAIN LEVEL OR DOMAINS FURTHER DOWN THE TREE TO HAVE SIGNATURES THAT EVERYBODY CAN EASILY VALIDATE WITHOUT A TREMENDOUS AMOUNT OF MANUAL INTERVENTION.
NOW, WITH THAT BACKGROUND, THE GOOD NEWS IS THAT ON A STRICTLY TECHNICAL LEVEL, SIGNING THE ROOT IS A SIMPLE OPERATION. THE SOFTWARE EXISTS. AND ALL OF THE TECHNOLOGY WORKS. AND IF WE REALLY WANTED TO DO THIS, WE COULD -- I COULD GO BACK TO THE OFFICE ON MONDAY AND I COULD TELL MY STAFF, " OKAY, WE'RE GOING TO START SIGNING THE ROOT ZONE."
HOWEVER, THERE ARE A FEW PROBLEMS WITH THAT SOLUTION. THE FIRST IS THE NAME ROOT SERVERS THEMSELVES AT THIS TIME ARE NOT READY TO START RECEIVING A SIGNED ZONE. ONE OF THE THINGS SIGNING A ZONE DOES IS IT INCREASES THE SIZE OF A FILE AND THE DATA IS RETURNED FAIRLY DRAMATICALLY, AND IN ORDER TO MAKE SURE THE STABILITY OF THE ROOT ZONE IS NOT AFFECTED, WHAT WE'VE DONE IS ASKED THE COMMITTEE TO STUDY THIS ISSUE CAREFULLY, MAKE SURE THAT THE SOFTWARE IS READY, THAT THE SYSTEMS ARE READY, AND THAT ALL OF THOSE ESSENTIALLY MECHANICAL PARTS OF THE NETWORK ARE READY TO RECEIVE AND SERVE THIS DATA.
AND THEY'VE GIVEN US SOME TIME ESTIMATES ON WHEN THEY WILL BE READY AND WE'RE HOPING THAT THAT WILL BE SOMETIME BEFORE THE END OF THIS YEAR.
SO WE'RE VERY MUCH LOOKING FORWARD TO THAT.
THE OTHER ASPECT OF THIS QUESTION, WHICH IS SOMEWHAT TROUBLESOME, IS THE QUESTION OF WHO WILL ACTUALLY BE THE, QUOTE, UNQUOTE, OWNERS OF THE KEYS THAT WILL BE NECESSARY TO SIGN THE ROOT ZONE? AND IF YOU USE THE ANALOGY OF PGP WHICH I THINK MOST OF US ARE FAIRLY FAMILIAR WITH, THERE'S WHAT'S REFERRED TO AS THE SECRET PART OF THE KEY, WHICH HAS TO BE OWNED AND MAINTAINED AND PROTECTED BY AN INDIVIDUAL ORGANIZATION, AND THEN THERE'S THE PUBLIC PART OF THE KEY, WHICH IS WIDELY DISSEMINATED AND USED FOR THE VALIDATION OF THE SIGNATURES.
AND THESE QUESTIONS OF WHO SHOULD OWN THE PRIVATE PART OF THE KEY AND WHO SHOULD BE RESPONSIBLE FOR MAINTAINING THAT RELATIONSHIP -- EXCUSE ME FOR A MINUTE -- ARE EXTREMELY COMPLEX AND HAVE A LOT OF VERY INTERESTED PARTIES WHO WOULD LIKE TO HAVE INPUT INTO THAT PROCESS.
AND SO FOR THAT REASON, MY PURPOSE FOR BEING ON THE PANEL THIS MORNING IS TO REPORT ICANN'S POSITION IN THIS ISSUE, WHICH IS THAT WE ARE PROCEEDING DOWN TWO DISTINCT PATHS. THE FIRST PATH IS THAT WE WOULD LIKE TO GET THE ROOT ZONE MANAGEMENT INFRASTRUCTURE UPDATED TO THE POINT WHERE WE ARE READY TO PERFORM DNSSEC SIGNATURES PRIOR TO THE POINT WHERE THE ROOT ZONE SERVER OPERATORS ARE ACTUALLY READY TO RECEIVE THAT DATA. AND OUR HOPE IS THAT BY MOVING FORWARD WITH THAT AS QUICKLY AS POSSIBLE, WE CAN BE READY AS SOON AS THEY ARE AND ACCELERATE THE DEPLOYMENT OF DNSSEC TO THE EXTENT THAT WE'RE CAPABLE OF PROVIDING A CONTRIBUTION.
THE OTHER PATH THAT WE'RE TRAVELING DOWN IS ONGOING DISCUSSIONS WITH THE COMMUNITY IN REGARDS TO HOW THE SYSTEM OF MANAGING THE PRIVATE PARTS OF THE VARIOUS KEYS THAT ARE INVOLVED IN THIS PROCESS SHOULD BE DONE. AND THIS IS SOMETHING THAT I WOULD LIKE TO EMPHASIZE, WE ARE VERY OPEN TO INPUT ON AND NO FINAL DECISIONS HAVE BEEN MADE BY ANY STRETCH OF THE IMAGINATION. BUT IT IS SOMETHING THAT WE ARE EAGER TO MOVE FORWARD AND ATTEMPT TO COME TO RESOLUTION, ONCE AGAIN WITH A DEADLINE OF SOMETIME PRIOR TO WHEN THE ROOT ZONE SERVER OPERATORS ARE READY TO RECEIVE THIS INFORMATION.
SO THAT IN A NUTSHELL DESCRIBES THE ROOT ZONE PART OF THE PROCESS, AND I WILL THEN TRANSFER THE MICROPHONE TO MY DEAR FRIEND RAM MOHAN TO DISCUSS THE -- OH, TO JOHAN, I'M SORRY. I THOUGHT WE WERE GOING TO GO IN THIS ORDER, BUT WE WILL GO TO THE OTHER END. THANK YOU.
>>JOHAN IHREN: I THINK WE ARE IN RANDOM ORDER.
DO WE HAVE MY SLIDES? NEXT SLIDE, PLEASE. OKAY. SO I'M HERE AS A PROXY FOR THE SWEDISH REGISTRY, AND THAT'S NOT AS FARFETCHED AS IT MAY SOUND BECAUSE I WORK FOR A COMPANY THAT OPERATES MOST OF THE SLAVES FOR THE SWEDISH REGISTRY SO WE HAVE A RATHER TIGHT RELATIONSHIP ALREADY.
THE SWEDISH TOP-LEVEL DOMAIN IS SIZABLE AS IN SEVERAL,000 DELEGATIONS. SO IT'S NOT A SMALL TLD NOR IS IT ONE OF THE LARGEST, WHICH MAKES IT AN INTERESTING BUT NOT INSURMOUNTABLE PROBLEM TO ACTUALLY SIGN IT. AND THE DECISION TO SIGN SE HAS BEEN TAKEN, AND THIS IS FOR A NUMBER OF REASONS, ONE OF THEM BEING THE SWEDISH GOVERNMENT IS REALLY INTERESTED IN SEEING THIS HAPPEN.
NEXT SLIDE, PLEASE.
WE'VE BEEN WORKING ON THIS FOR A NUMBER OF YEARS NOW, AND JUST AS AN EXAMPLE, WE'VE BEEN RUNNING A SIGNED VERSION OF THE SE TLD IN PARALLEL WITH THE PRODUCTION ITSELF FOR MORE THAN TWO YEARS NOW AND IT'S BEEN WORKING VERY, VERY WELL. ON THE REGISTRY SIDE, WE HAVE SEEN DEVELOPMENT OF VARIOUS COMPONENTS THAT ARE NEEDED TO ACTUALLY MOVE THIS FROM JUST PROOF OF CONCEPT TECHNOLOGY INTO PRODUCTION-READY TECHNOLOGY, AND THAT IS ESPECIALLY ON THE SIDE OF KEY MANAGEMENT.
SO SUCH DEVELOPMENT IS VERY FAR ON THE WAY RIGHT NOW.
SE HAS SENT VARIOUS REPRESENTATIVES FROM SWEDEN, NOT ONLY FROM THE REGISTRY; HAVE BEEN FAIRLY ACTIVE IN ALL THE AREAS OF DNSSEC DEVELOPMENT.
NEXT SLIDE, PLEASE.
AS WE MOVE FROM THE TEST BED OVER INTO PRODUCTION, WE GET DOWN INTO THE NITTY-GRITTY, WHICH IS A COMMITMENT TO HAVE ALL THE SLAVES FOR THE SWEDISH TLD RUN THE DNS COMPLIANCE SOFTWARE BY THE BEGINNING OF THE SUMMER, JUNE 2005. THE PLAN IS TO HAVE THE SIGNED ZONE IN PRODUCTION AFTER SUMMER. THIS WILL BE JUST THE ZONE ITSELF BEING SIGNED, SO IT WILL NOT INITIALLY BE POSSIBLE FOR DELEGATION FROM DOT SE, DOMAIN NAME OWNERS IN SE HAVE THEIR DELEGATIONS SIGNED. THAT WILL BE THE FIRST STEP AND WE HOPE TO BE ABLE TO TAKE THAT BEFORE THE END OF THE YEAR.
NEXT SLIDE, PLEASE.
ONCE WE HAVE THIS IN PLACE,, THE PLAN AND THE HOPE IS THAT WE WILL BE ABLE TO REACH A LEVEL OF -- HOW DO I PUT IT? MAKE THIS RELEVANT EVEN WITHOUT HAVING TO SIGN EVERY SINGLE DOMAIN UNDER SE, EVEN WITHOUT HAVING TO DO VALIDATION IN EVERY RESOLVER AROUND THE PLANET, BECAUSE THOSE TWO THINGS ARE MASSIVE PROJECTS THAT WILL TAKE MANY YEARS.
BUT THE WAY WE LOOK AT THIS PROBLEM, EVEN IF WE ONLY MANAGE TO SIGN A FEW TENS OF CHILDREN, LIKE, FOR INSTANCE, INTERNET BANKS, GOVERNMENT, MASS MEDIA, ET CETERA; AND EVEN IF WE JUST MANAGE TO GET A FEW DOZEN OF VALIDATORS TO GET THE SIGNATURES, AND THOSE ARE THE VALIDATORS IN THE MAJOR ISPS, WE WILL, BY JUST REACHING OUT TO A FEW TENS OF ENTITIES LIKE CONTENT PROVIDERS AND MAJOR ISPS, BE ABLE TO HAVE, FOR INSTANCE, PERHAPS 90% OF INTERNET BANKING ACTIVITIES IN SWEDEN ACTUALLY BE COVERED BY DNS ACCREDITATION, ET CETERA.
AND WE REGARD THIS AS A VERY GOOD THING.
AND IN SWEDEN, WE ALSO HAVE A FAIRLY LARGE INTEREST IN ENUM TECHNOLOGY, AND TO SEE THE ENUM INFRASTRUCTURE SIGNED IS A NATURAL FOLLOW-UP ON THIS.
BUT IT WILL BE AFTER SIGNING UP THE ACTUAL TLD.
OKAY, NEXT SLIDE.
I THINK I AM DONE.

>>DOUG BARTON: THANK YOU, JOHAN.
AND WE WILL TAKE QUESTIONS AT THE END OF THIS PANEL DISCUSSION.
AND I WOULD LIKE TO NEXT ASK ED LEWIS TO DO HIS PANEL PRESENTATION.
AND IF WE COULD KEEP IN MIND THAT WE ARE RUNNING A BIT SHORT ON TIME SINCE WE STARTED A BIT LATE.
>>ED LEWIS: OKAY.
IN THE INTEREST OF BREVITY, WE HAVE DONE A TEST BED.
WE DID IT UNDER THE DOT U.S. DOMAIN.
THERE'S A RESULT FROM THAT THAT I WILL PRESENT LATER.
SO I WILL SKIP WHAT WE HAVE DONE.
WE HAVE BEEN PARTICIPATING IN EXTERNAL WORK WITH OTHER GROUPS.
WE ARE FINDING OUR COMMITMENT TO DNSSEC HAS BEEN PUMPED DOWN TO THE ECONOMICS OF THIS.
WE'D LOVE TO COMMIT TO DNSSEC.
WE HAVE A FEW ISSUES.
ONE ISSUE IS STABILITY VERSUS INNOVATION.
WE HAVE VERY -- A NEED TO PROVIDE A GOOD SERVICE.
WE HAVE SLAS TO MEET.
STABILITY IS GOOD FOR THAT.
THE COMMUNITY WANTS US TO BE STABLE.
INNOVATION IS INHERENTLY RISKY AND DNSSEC IS AN INNOVATION.
SO WE NEED TO BALANCE OFF THOSE TWO COMPETING GOALS.
DOING THIS WITH AN ECONOMIC MODEL WHICH KEEPS US EFFICIENT IN WHAT WE SPEND MAKES IT TOUGH.
WE DON'T HAVE A LOT OF MONEY TO SPEND AT INNOVATION; WE DON'T HAVE A SLUSH FUND FOR TECHNOLOGY AND ENGINEERING.
WE'RE TRYING TO BE EFFICIENT IN WHAT WE CHARGE AND WHAT WE SPEND ON THE SERVICE.
IF I WERE TO BE ASKED WHAT I THINK ARE THE GATING QUESTIONS, THE QUESTIONS THAT PREVENT US FROM CHARGING FULL-STEAM INTO DNSSEC, THESE ARE THE LIST OF QUESTIONS.
WE HAVEN'T DONE A LARGE-SCALE DNSSEC TEST BED.
WE HAVE DONE SOME SUSTAINED TESTS BUT HAVEN'T DONE MILLIONS OF NAMES AND LARGE REGISTRIES.
I DON'T BELIEVE ANYBODY HAS A LOT OF EXPERIENCE WITH THAT.
IT'S ALSO POSSIBLE THE TECHNOLOGY COULD HURT OUR REGISTRANTS AND WE WOULD NOT WANT TO DEPLOY SUCH A FEATURE IF IT DID.
THE QUESTION IS CAN WE STUDY AND ADD DNSSEC WHILE STILL KEEPING THE SAME LEVEL OF SERVICE.
THAT'S THE ECONOMICS ISSUE I MENTIONED EARLIER. AND ALSO, SINCE OUR TRUE CUSTOMERS ARE REGISTRARS, AND THE REGISTRARS ARE THE PEOPLE BETWEEN US AND THE REGISTRANTS, WILL THE REGISTRARS WANT TO PLAY?
WILL THEY BE ABLE TO PUSH THIS?
WILL THEY WANT TO SELL DNSSEC TO THEIR CUSTOMERS TO MAKE IT WORTHWHILE FOR US TO BE PROVIDING THE SERVICE AND DEPLOYING THIS?
AND I BELIEVE THAT IS THE -- MY BRIEF SLIDES.
AND I WILL TURN IT OVER TO THE NEXT SPEAKER.
>>RAM MOHAN: THANK YOU, ED.
RAM MOHAN.
AND I WANTED TO TALK ABOUT DOT INFO, WHAT OUR PLANS ARE, AS WELL AS AN UPDATE ON DOT ORG.
ON THE TECHNICAL SIDE, WE'RE LOOKING AT A COUPLE OF ISSUES THAT ARE UNDER REVIEW.
IN ZONE TRAVERSAL, ZONE ACCESS TODAY IN THE ZONES THAT WE ARE WORKING WITH, IT'S GOVERNED UNDER AN ACCEPTABLE USE AGREEMENT.
SO EVEN THOUGH THE ZONE FILE IS ACCESSIBLE TO EVERYBODY, YOU HAVE TO ACTUALLY SIGN A CONTRACT, PROVIDE YOUR IP ADDRESS, AND YOU WILL BE GIVEN A USER NAME AND PASSWORD.
SO THERE IS AN ISSUE OF ZONE TRANSVERSAL IN DNSSEC.
WE DON'T THINK IT'S A -- WE DO RATE-LIMIT WHO IS RECORD ACCESS.
IT'S NOT A PRIVACY ISSUE UNLESS IT CAN BE COMBINED WITH WHOIS RECORD ACCESS.
THERE IS A LEGAL AND POLICY EVALUATION UNDERWAY TO GET TO WHAT IT TAKES TO HAVE -- IN THE AREA OF KEY ROLLOVER, WE'RE CLOSELY OBSERVING THE PLANS OF OTHER REGISTRIES, .BR, .SE.
YOU WILL HEAR MORE.
WE ARE CLOSELY KEEPING A WATCH ON THAT, BECAUSE THAT IS ANOTHER IMPORTANT ISSUE THAT'S NOT FULLY SOLVED YET.
ON THE BUSINESS AND POLICY ISSUES UNDER REVIEW, WE'RE LOOKING AT PRICING TO SEE WHETHER THE REGISTRIES SHOULD CHARGE A FEE FOR DNSSEC NAMES WITHIN A ZONE ON A PER-NAME BASIS.
CURRENT TOP PROCESS IS NOT TO CHARGE A FEE.
BUT IT'S STILL AN OPEN TOPIC.
ON MULTIPLE-SIGNATURE STORAGE, IT'S CERTAINLY POSSIBLE THAT THE REGISTRY RECEIVE MULTIPLE SIGNATURES WITH INSTRUCTIONS TO APPLY EACH ONE IN SEQUENCE AS THEY EXPIRE.
IT'S A NEW PROCESS, AND IF -- THERE ARE IMPLEMENTATION PLANS AND A FEE, IF ANY, AGAIN, ARE UNDER REVIEW.
THIS IS REGISTRANT CONVENIENCE.
HOWEVER, THERE IS REGISTRY AND POTENTIALLY REGISTRAR IMPACT.
AND THE FINAL BUSINESS POLICY ISSUE UNDER REVIEW IS REGISTRAR AND/OR REGISTRANT SIGNATURE EXPIRATION NOTIFICATION, WHAT ARE THE RIGHT POLICIES TO FOLLOW HERE?
SHOULD THE REGISTRAR OR THE REGISTRANT BE NOTIFIED IF THEIR SIGNATURE IS ABOUT TO EXPIRE?
AND WHAT IS AN ACCEPTABLE WAY OF NOTIFYING THAT DOESN'T PROMPT LEAKS AROUND THE EDGE?
BECAUSE THAT IS CERTAINLY OPEN WHEN WE TRY TO DO A NOTIFICATION.
AND IT'S ALSO UNCLEAR WHETHER THIS IS SOLELY A REGISTRY FUNCTION OR IT'S A SHARED FUNCTION BETWEEN REGISTRIES AND THEN REGISTRARS.
AND THE SAME QUESTION OF FEES COMES UP.
SO AT THE END, IN 2005, IN INFO, WE'RE LOOKING AT A TEST BED LAUNCH IN ITS EARLY PLANNING STAGES.
WE ARE IN THE MIDDLE OF OBSERVING OTHER REGISTRY IMPLEMENTATIONS AND WORKING WITH THE COMMUNITY ON STANDARDIZING DNSSEC EXTENSIONS OVER THE EPP, THE STANDARD PROTOCOL THAT REGISTRARS AND THE REGISTRY COMMUNICATES WITH.
IN ORG, A DNSSEC COMMITTEE HAS BEEN FORMED UNDER THE LEADERSHIP OF BARBARA FRASER, WHO IS ON THE BOARD OF PIR.
AND THIS IS A JOINT COMMITTEE THAT HAS A SPECIFIC FOCUS, GIVEN THAT DNSSEC IS A STRATEGIC GOAL FOR DOT ORG.
AND, AGAIN, TEST BED PLANNING -- LAUNCH IS IN THE EARLY PLANNING STAGES.
>>FREDERICO NEVES: OKAY.
IN THE CASE OF .BR, A LITTLE INFORMATION ABOUT THE REGISTRY.
WE ARE NOT FOR PROFIT.
WE ARE OPERATING CLOSELY TO THE REGISTRANTS SINCE 1997, SMALL REGISTRY.
WE ARE THE NIR TO BRAZIL, TOO.
AND WE HAVE NEARLY 800,000 DOMAIN NAMES, BUT DIVIDED IN 58 ZONES.
.COM.BR IS ALMOST 92% OF THE DOMAIN NAMES.
WHAT WE HAVE BEEN DOING TO DEPLOY DNSSEC, WE HAVE ALREADY UPDATED OUR DNS PROVISIONING.
WE NOW HAVE IN THE THIRD QUARTER OF 2004, WE TOOK CONTROL OF ALL OF OUR DNS SERVERS.
WE ARE -- IN THE END OF SECOND QUARTER 2005, WE WILL HAVE ALL DNS SERVERS SUPPORTING DNSSEC, THE CURRENT STANDARD.
WE ARE NOW MAKING CHANGES TO OUR PROVISIONING SYSTEM TO COLLECT DS RECORDS AND GENERATE JOURNAL INCREMENTS, BASICALLY, DS AND NSEC.
AND WE ARE ENDING -- MOVING A PROTOTYPE TO A PRODUCTION BEYOND AN INCREMENTAL IXFR/PROXY SIGNER.
THIS IS SOMETHING WE WANT TO CONTROL.
WE WILL NOT BE USING THIRD PARTIES FOR SIGNING OUR ZONES.
AND OUR DEPLOYMENT PLANS.
WE ALREADY HAVE VERY GOOD SECURE TRUST RELATIONSHIP WITH THE REGISTRANTS, SO WE HAVE SECURE INTERACTIONS WITH THEM.
SO COLLECTING DS RECORDS OR KEYS IS -- WILL NOT BE A PROBLEM.
WE DON'T HAVE A WEAK LINK IN THIS PART.
OUR INITIAL DEPLOYMENT WILL BE WITH SMALL ZONES, .BR, .GOV.BR AND .ENG.BR.
WE ARE PLANNING THIS FOR THE END OF THIS YEAR.
AND OTHER ZONES, DIFFERENTLY FROM DNSSEC, THE -- WE HAVE SOME ISSUES WITH THE ZONE BLOCKING PROBLEM.
SO AS TODAY, WE CANNOT MITIGATE THE COLLECTION OF INFORMATION FROM OUR WHOIS SERVER.
AND THIS IS ONLY BE AVAILABLE IN THE MIDTERM.
WE ARE EXPECTING TO HAVE OTHER ZONES SIGNED ONLY BY THE BEGINNING OF 2007 WHEN WE GET IRIS DEPLOYED.
IRIS IS NOT A PLUG-IN TO WHOIS, SO IT DEPENDS ON DEPLOYMENT OF CLIENT SOFTWARE.
SO IT WILL TAKE SOME TIME.
BUT THAT'S OUR PLANS.

>>DOUG BARTON: OKAY.
THANK YOU, FREDERICO.
IF I COULD, WE HAVE SOME QUESTIONS FOR THE PANEL.
AND I'M ALSO MINDFUL THAT WE NEED TO ACCELERATE THE PROCESS JUST A BIT TO TRY TO KEEP WITH THE POSTED SCHEDULE.
BUT IF WE CAN, I'D LIKE TO DIVERT MOMENTARILY, BECAUSE RAM AND FREDERICO BOTH MENTIONED A VERY IMPORTANT TOPIC IN THE DNSSEC WORLD THAT I WAS WONDERING IF WE COULD GET JUST A MINUTE OR TWO OF ELABORATION ON.
AND THAT'S THE ZONE-WALKING TOPIC.
WOULD ONE OF YOU LIKE TO TAKE A MINUTE AND EXPLAIN IN MORE DETAIL WHY THAT TOPIC IS IMPORTANT?
>>FREDERICO NEVES: THE ZONE-WALKING PROBLEM IS -- ONE OF THE THREE FEATURES OF DNSSEC IS THE SIGNED PROOF OF NO EXISTENCE OF RECORDS.
AND FOR DOING THAT IN A (INAUDIBLE) SIGNED WAY, WITHOUT HAVING TO HAVE PRIVATE KEYS ON DNS SERVERS, WE CONSTRUCT A CHAIN OF END OF ZONE WITH RECORDS THAT POINT ONE TO THE OTHER.
AND PROVIDING THIS CIRCLE OR CHAIN IN THE ZONE.
SO IF YOU GET A -- ASK FOR -- IF THE ZONE HAS DOMAIN A AND C AND U.S. CORE DOMAIN B, YOU GET REFERENCE FOR A, NEXT DOMAIN, NEXT SECURE DOMAIN C.
SO THE RESOLVER CAN HAVE -- CAN INFER THE INFORMATION THAT B DOESN'T EXIST ON A SIGNED WAY.
SO HAVING THIS CIRCLE OF REFERENCE, SOMEBODY CAN START FROM ONE KNOWN DOMAIN NAME AND HAVE ALL THE NAME SPACE -- ALL THE DELEGATED NAME SPACE IN THAT ZONE.
FOR SOME REGISTRIES, THIS COULD BE A PROBLEM; FOR OTHERS, NO.
BUT THIS IS FOR A LONG TIME A DISCUSSION IN THE IETF.
AND FROM .BR SIDE -- VIEW OF THIS, THIS PROBLEM, WE ARE TAKING A PRAGMATICAL WAY.
IF WE HAVE TECHNOLOGY TO MITIGATE THE USE OF THIS INDEX IN THE PROTOCOL THAT PROVIDES INFORMATION FOR DOMAIN NAMES, THAT IS, TODAY'S WHOIS, BUT WILL BE A NEW PROTOCOL ALREADY APPROVED BY THE IETF CALLED IRIS, AND WE CAN HAVE A DEFAULT PROFILE FOR NEW AUTHENTICATED USERS WITH VERY LOW AMOUNT OF INFORMATION, THIS COULD BE DEPLOYED FOR LARGE ZONES.
THIS IS OUR OPINION.
BUT THIS IS WHY WE ARE PLANNING TO DEPLOY THIS FOR SMALL ZONES IN THE BEGINNING.
>>RAM MOHAN: FROM A GTLD PERSPECTIVE, ONE OF THE LIMITING FACTORS THAT WE -- IS THAT IT IS HARDER TO DO FROM WHAT FREDERICO WAS TALKING ABOUT IN A CCTLD, IS THAT A GTLD REGISTRY HAS CONTRACTUAL REQUIREMENTS ON WHAT INFORMATION IS PROVIDED IN THE WHOIS.
SO YOU CAN'T JUST SAY YOU'RE GOING TO LIMIT SOME OF THAT INFORMATION.
HOWEVER, IN THE REGISTRIES THAT WE WORK WITH, IN BOTH INFO AND OUR ADVICE TO DOT ORG, IS CONTRARY TO THE POPULAR CONCEPTION THAT THE ABILITY TO EXTRACT THE ZONE USING DESIGN TRAVERSAL TREE WALKING IN DNSSEC, THERE IS THIS POPULAR MISCONCEPTION THAT THIS IS A PRIVACY PROBLEM.
AND MY PERSPECTIVE IS THAT, BY ITSELF, IT'S NOT A PRIVACY PROBLEM.
THE ZONE FILE IS AVAILABLE FOR NO COST TO ANYBODY WHO COMES AND ASKS FOR IT.
IT BECOMES A PRIVACY PROBLEM IF YOU COMBINE THAT WITH UNTRAMMELLED ACCESS TO THE WHOIS OR TO A DIRECTORY LOOKUP OF THE ASSOCIATED CONTACTS WITH THE NAMES. AND EPP ITSELF PROVIDES SOME FUNCTIONALITY WITH THE RFC VERSION.
THERE IS A DISCLOSED ELEMENT THAT ALLOWS PRIVACY.
BUT IN GENERAL, FROM A GTLD PERSPECTIVE, ONE WAY TO MITIGATE THE PROBLEM IS TO ENSURE THAT THE WHOIS ACCESS IS MONITORED CAREFULLY AND THAT RATE LIMITS ARE PUT IN PLACE.

>>DOUG BARTON: THANK YOU BOTH.
THIS IS ONE OF THE MORE CONTROVERSIAL ASPECTS OF THE DEPLOYMENT OF THE PROTOCOL, AND IT'S SOMETHING THAT THE REGISTRIES ON AN INDIVIDUAL BASIS, BOTH THE CCS AND THE GTLDS, ARE CURRENTLY DISCUSSING AND WILL NEED TO COME TO DECISIONS ON BEFORE CONSIDERING DEPLOYMENT.
SO THANK YOU BOTH FOR THAT.
FINALLY, QUICKLY, WE HAVE TWO QUESTIONS THAT WE'D LIKE TO PRESENT TO THE PANEL.
FIRST OF ALL, FOR ED AND FREDERICO, WHO HAVE ALREADY RUN TEST BED PROJECTS WITH YOUR DOMAINS, WHAT WAS THE MOST SURPRISING THING THAT YOU LEARNED AS PART OF THAT PROCESS?
>>ED LEWIS: LET'S SEE.
THE TEST BED WE RAN INVOLVED REGISTERING DNS INFORMATION.
BUT I THINK THE -- WHAT WE LEARNED -- WHAT WE'VE LEARNED THAT'S MOST SURPRISING REALLY DIDN'T COME OUT OF THAT TEST BED.
IT WAS THAT THE PROBLEM OF UPDATING ZONES THAT ARE LARGE FREQUENTLY, LIKE ON THE ORDER OF 15 MINUTES OR LESS, IS GOING TO BE MORE OF A CONCERN WITH DNSSEC, BECAUSE PEOPLE WILL BE MAKING CHANGES TO THE ZONE, AND WE HAVE TO PROPAGATE THAT.
SO WE HAVE TO PROPAGATE A LOT MORE INFORMATION FROM OUR DATABASE INTO OUR MASTER SERVER, INTO THE AUTHORITATIVE SLAVE SERVERS THAT WE USE.
I THINK THAT'S AN AREA OF THE DNSSEC OPERATIONS THAT DURING THE PROTOCOL DEVELOPMENT WE DID NOT EVEN THINK ABOUT.
>>FREDERICO NEVES: WE HAVEN'T RUN TEST BEDS PUBLICLY.
I THINK THE ONES THAT JOHAN FROM SWEDISH, BUT WE HAVE BEEN DOING INTERNAL TESTS.
AND OUR PROVISIONING WILL TAKE CARE OF WHAT ED IS TELLING.
WE ARE PLANNING -- TODAY, WE WRITE A JOURNAL FOR MODIFICATIONS.
WE ARE CHANGING THIS JOURNAL TO COLLECT DS AND NSEC RECORDS.
SO THE APPLICATION THAT PROCESSES THIS JOURNAL TODAY WILL GENERATE THE SIGNATURE RECORDS, AND WE'LL PUT THIS IN THE ZONE.
AND THIS WILL BE -- PROVISION IT THROUGH IXFR.
AND IN -- SOMETIMES IN RE-SIGNING, WE ARE PLANNING ON INCREMENTAL ZONE RE-SIGNING.
SO, ACTUALLY, WE'LL BE PUSHING IXFR WITH NEW SIGNATURES MOSTLY DURING ALL THE DAY.

>>JOHAN IHREN: WELL, FROM A SWEDISH PERSPECTIVE, WE ACTUALLY HAVEN'T SEEN MUCH PROBLEMS.
THE MAJOR SURPRISE TO US HAS PROBABLY BEEN THE AMOUNT OF TIME THAT IT HAS TAKEN TO ACTUALLY GET THE PROTOCOL PUBLISHED AND FULLY DONE.
BUT IN HINDSIGHT, WE SHOULD HAVE PERHAPS EXPECTED THAT, BECAUSE IT'S BEEN IN PREPARATION FOR TEN YEARS.
BUT SINCE WE ARE IN A SENSE THE FORERUNNERS HERE, TAKING IT SLOW AND, ACTUALLY, WITHOUT A SIGNIFICANT AMOUNT OF EXTERNAL PRESSURE IS NOT A BAD ENVIRONMENT TO BOOTSTRAP THIS THING.
SO I DON'T THINK WE ARE ACTUALLY DISPLEASED AT ALL THAT IT HAS TAKEN SOME TIME AND WE'VE BEEN ABLE TO WORK IT THROUGH IN A SLOW AND CAREFUL MANNER.
>>DOUG BARTON: OKAY.
THANK YOU.
AND ONE LAST QUESTION.
FOR THOSE OF THE REGISTRIES WHO HAVE NOT YET IMPLEMENTED A TEST BED, WHAT IMPEDIMENTS HAVE YOU FOUND TO THAT PROCESS?
AND WHAT RESOURCES COULD BE APPLIED THAT WOULD ALLOW YOU TO MOVE FORWARD WITH THAT SORT OF PROJECT?
>>RAM MOHAN: LET ME TAKE THAT FIRST.
I THINK THE SINGLE BIGGEST IMPEDIMENT THAT I'VE BEEN SEEING IS, IN GENERAL, APATHY DOWNSTREAM, IF YOU LOOK AT REGISTRARS OR LOOK AT OTHER PARTS OF THE STREAM HERE, THAT HAVE TO PARTICIPATE, THERE IS LITTLE INTEREST OR THERE IS LITTLE KNOWLEDGE OF WHY DNSSEC IS ACTUALLY IMPORTANT, WHY ANYBODY SHOULD CARE.
AND UNLESS THAT PARTICULAR PIECE IS FIXED, I THINK THERE'S GOING TO BE A LOT OF HARD SLOGGING TO MAKE DNSSEC ACTUALLY WORK IN A TIMELY MANNER.
SO IN TERMS OF RESOURCES, I THINK WE ALL IN THE COMMUNITY WHO UNDERSTAND WHY DNSSEC IS ACTUALLY IMPORTANT AND WHY WE HAVE TO, YOU KNOW, WORK ON IMPLEMENTING IT, I THINK WE HAVE TO SIGNIFICANTLY INCREASE THE AMOUNT OF EDUCATION AND, DARE I SAY IT, MARKETING OF WHY THIS IS AN IMPORTANT ISSUE TO BE RESOLVED.
>>ED LEWIS: I'LL TALK FROM THE EXPERIENCE OF HAVING ACTUALLY RUN THE -- A TEST BED.
WE TRIED TO ENCOURAGE WIDE PARTICIPATION.
AND WE DID NOT HAVE WIDE ACCEPTANCE TO THAT.
WE DID HAVE PARTICIPANT -- ONE PARTICIPANT TO TEST WITH US.
I ALSO WANT TO POINT OUT THAT THERE ARE A LOT OF -- IN THE U.S. GOVERNMENT ESPECIALLY -- RECOMMENDATIONS THAT DNSSEC GET DEPLOYED.
THOSE RECOMMENDATIONS AREN'T TRANSLATING INTO PEOPLE SAYING, "WE'VE GOT TO KNOW MORE AT THE OPERATIONAL LEVEL AND WE'VE GOT TO FIND TEST BEDS."
I THINK WHAT THE IMPEDIMENT WOULD BE IS, HOW DO YOU GET COMMERCIAL ENTITIES WILLING TO SPEND RESEARCH MONEY OR, YOU KNOW, ADVANCE DEVELOPMENT MONEY THAT THEY MAY OR MAY NOT HAVE IN THEIR BUDGET ALREADY INTO WORKING INTO A TEST BED THAT WOULD GET US WHAT I THINK WE NEED THE MOST, IS THE WIDESCALE, LARGE DEPLOYMENT TO TEST THE LARGE-SCALE EFFECTS OF DNSSEC THAT I THINK HAVEN'T BEEN FULLY TESTED.
>>DOUG BARTON: ALL RIGHT.
THANK YOU ALL VERY MUCH.
ARE THERE ANY QUESTIONS FROM THE AUDIENCE AT THIS POINT?
EXCELLENT.
BILL.
>>BILL MANNING: THIS IS BILL MANNING --
>> MIKE'S NOT ON.
>>BILL MANNING: IT'S NOT ON?
I CAN SPEAK LOUD.
THIS IS BILL MANNING.
AND, RAM, YOU WERE SAYING THAT THE -- IT'S ALREADY SCROLLED PAST THE TOP.
YOU WERE SAYING THAT THERE IS LITTLE IN THE WAY OF PROVIDING IMPETUS OR INTEREST TO PEOPLE TO DO DNSSEC.
I HAVE A SMALL SET OF PEOPLE WHO WOULD BE MORE THAN HAPPY TO REPLACE YOUR WEB SITE WITH SOMETHING THAT LOOKS VERY SIMILAR AND HAVE MANY OF YOUR CUSTOMERS, THEN, FIND THAT TO BE AN UNACCEPTABLE ALTERNATIVE OF HAVING MOST OF YOUR CUSTOMERS REDIRECTED SOMEWHERE ELSE.
IS THAT SUFFICIENT?
>>RAM MOHAN: I THINK IT'S A SUFFICIENT THREAT FOR THOSE WHO ARE CLUEFUL ABOUT IT.
BUT, REALLY, THE ISSUE IS, YOU'VE GOT 150 OR SO REGISTRARS, AND YOU'VE GOT A NUMBER -- MULTIPLE OF THAT OF FOLKS DOWNSTREAM.
AND TO MAKE THAT SAME ISSUE THAT YOU POINTED OUT, WHICH STANDS CRYSTAL CLEAR AS A REAL THREAT, I THINK THE JOB IS TO GO TAKE THAT MESSAGE AND PASS THAT DOWN THE CHAIN.
BECAUSE I GET IT, BUT I'M NOT SURE THAT EVERYBODY IN THE STREAM GETS IT.
AND I THINK THAT'S AN IMPORTANT POINT.
>>BILL MANNING: OKAY.
SO IF YOU HAVE 150 DOWNSTREAM PEOPLE THAT NEED TO GET THIS, WE WILL BE HAPPY TO WORK WITH YOU IN ENLIGHTENING THEM.
>>SABINE DOLDERER: YEAH, SABINE DOLDERER, I'M FROM DNIC.
AS I UNDERSTAND, TO IMPLEMENT DNSSEC ON A MORE BROAD BASIS IS A VERY COSTLY AND EDUCATIONAL EFFORT, AS YOU HAVE TO DEPLOY IT IN THE ROOT, IN THE NORMAL TLDS WITHIN ALL CUSTOMER DATABASES, YOU HAVE TO INCORPORATE IT IN ALL RESERVES WORLDWIDE IN EACH PC, MACINTOSH, UNIX WORKSTATIONS.
HAS EVERYBODY -- HAVE SOME OF YOU MADE A SORT OF ASSESSMENT ABOUT THE COST OF THESE EFFORTS AND IF THESE COSTS ARE IN SOME WAY RELATED ABOUT THE THREAT WE ARE FACING?
I THINK THAT'S ACTUALLY -- IS THERE A SORT OF MARKET AWARENESS THAT WE REALLY HAVE TO REPLACE NOT ONLY THE DNSSEC IN THE ROOT, BUT, REALLY, DNS ON EACH AND EVERY SERVER?
WE HAVE TO EDUCATE THE USERS, IF IN CASE OF SUCH A THREAT, HOW THEY HAVE TO DEAL WITH.
WE HAVE SEEN IN THE PRESENTATION THAT PEOPLE AT THE MOMENT ARE ALREADY ANNOYED WHEN THEY SAY WRONG CERTIFICATE.
THEY CLICK AND SAY, OF COURSE I GO AHEAD WITH THIS INFORMATION.
WE HAVE TO EDUCATE THE PEOPLE ON THAT TO IF THEY GET WRONG DNS INFORMATION, HOW LIKELY IS THEY GET WRONG DNS INFORMATION.
WE HAVE SEEN THE PRESENTATION COMING FROM BILL MANNING.
AND ACCORDING TO THAT, I REALLY MISSED THE POINT.
I KNOW -- OR I THINK EVERYBODY HERE IN THE ROOM KNOWS -- THAT LOCAL NETWORKS YOU GET THEM IN LAUNCHES OF AIRPORTS OR IN MEETING ROOMS OR HOTELS ARE NOT SAFE.
THEREFORE PEOPLE USE VPN, WE EDUCATE OUR STUFF TO USE VPN.
AND THEREFORE IT'S JUST THE QUESTION, HAVE SOMEBODY REALLY MAKE THE MARKET RESEARCH, HAVE YOU LOOKED ON THE COSTS WHICH ARE ASSOCIATED TO THAT?
AND IS THE INDUSTRY, ARE THE PEOPLE WILLING TO TAKE THESE COSTS?
THANKS.

>>DOUG BARTON: COULD I ASK JOHAN TO PICK UP THAT QUESTION.
BECAUSE I KNOW YOU HAVE DONE A LOT OF WORK WITH THE INDUSTRY IN SWEDEN.
>>JOHAN IHREN: I DON'T HAVE THE ANSWER TO WHAT THE TOTAL COST TO DO THIS WOULD BE.
BUT I HONESTLY DON'T THINK WE WANT TO GO THERE.
BECAUSE DNSSEC TO THE LEVEL WHERE EVERY, IN YOUR WORDS, PC AND MACINTOSH IS UPDATED AND DOES VALIDATION, ET CETERA.
WELL, THAT'S A PROJECT THAT SPANS A LONGER TIME THAN I'M PREPARED TO INVEST IN THIS PERSONALLY.
BUT WE DON'T NEED THAT.
IF YOU LOOK AT THE SWEDISH EXAMPLE, AND ONE OF THE SLIDES I HAD, FROM THE SWEDISH PERSPECTIVE, WE ARE PREPARED TO DECLARE VICTORY IF WE MANAGE TO GET, LET'S SAY, JUST, TONGUE IN CHEEK, 100 CHILDREN SIGNED, IF THEY ARE THE RIGHT 100 CHILDREN.
LIKE THE INTERNET BANKS, LIKE THE MASS MEDIA, LIKE THE GOVERNMENT, PUBLIC SERVICES, ET CETERA.
AND THEN IF WE MANAGE TO GET THE MAJOR ISPS TO DO VALIDATION.
AND LET'S SAY WE HAVE 20 MAJOR ISPS.
AND BY REACHING 120 ORGANIZATIONS, SUDDENLY MORE THAN 90% OF THE INTERNET BANKING ACTIVITIES WILL BE COVERED BY DNSSEC.
SO VALIDATION IS USUALLY NOT DONE IN THE INDIVIDUAL PC; IT'S DONE BY THE ISP.
>>SABINE DOLDERER: YEAH.
BUT IT'S THE -- BY YOUR LOCAL ISP.
BUT IF WE SEE THE EXAMPLE BILL MANNING ADVISES US, YOU DON'T USE THE RESOLVER OF YOUR LOCAL ISP, BUT YOU USE THE RESOLVER OF THE GUY AT THE MEETING FLOOR.
WHO GIVES YOU ACTUALLY WRONG INFORMATION.
>>JOHAN IHREN: THAT IS ACTUALLY A DIFFERENT PROBLEM.
I'M NOT SAYING IT'S NOT A PROBLEM.
BUT IF YOU LOOK AT THE INTERNET -- WELL, THE INTERNET TOPOLOGY IN GENERAL, THE BASIC ASSUMPTION IS THAT YOU HAVE TO TRUST YOUR LOCAL RESOLVER.
>>SABINE DOLDERER: AND THAT'S WHY I AM USING UPM, BECAUSE I KNOW WHAT MY LOCAL RESOLVER IS.
>>JOHAN IHREN: IF THE BAD MAN IS BETWEEN YOU AND YOUR LOCAL RESOLVER, IF THE BAD MAN IS SOMEWHERE IN THE TELEPHONE LINE BETWEEN YOU AND YOUR ISP, THEN YOU WILL HAVE NEED FOR LOCAL VALIDATION.
BUT THAT IS NOT THE TYPICAL CASE.
IF YOU LOOK AT -- WELL, EVERY HOME OWNER IN SWEDEN WITH A DSL CONNECTION, WELL, HE HAS TO TRUST HIS LOCAL ISP REGARDLESS.
AND IF THIS LOCAL ISP DOES VALIDATION, HE GETS THE BENEFIT FROM THIS VALIDATION WITHOUT HAVING TO DO ANYTHING HIMSELF.
>>SABINE DOLDERER: YES.
BUT DO YOU THINK THAT THERE IS A CHANCE THAT BETWEEN YOU -- YOUR ADSL AND YOUR LOCAL ISP IS A MAN IN THE MIDDLE ATTACK LIKELY?
>>JOHAN IHREN: OF COURSE THERE'S A CHANCE.
I PERFECTLY AGREE.
BUT YOU SHOULDN'T LOOK AT THIS AS THE FINAL SOLUTION TO EVERY PROBLEM.
YOU SHOULD LOOK AT THIS AS SOMETHING THAT IF YOU DEPLOY IT THE WAY WE PROPOSE TO DO IT, YOU REACH A MAJOR BENEFIT WITH A LIMITED COST.
>>SABINE DOLDERER: OKAY.
THANKS.
I AM FINISHED.
>>ALLISON MANKIN: I'D LIKE TO JUST MENTION THAT THERE WAS ACTUALLY A CNN STORY THIS PAST NOVEMBER, AMAZON LOST SOME MONEY BECAUSE A NUMBER OF ISPS HAD A DNS ATTACK WHERE THEY WERE HACKED JUST EXACTLY THE WAY JOHAN SAYS.
AND THE AMAZON DOMAIN NAME WAS REPLACED BY A NETWORK PHARMACY'S NAME IN ORDER TO GET THEIR PAGE IN FRONT OF EYES.
AND IT'S EXACTLY THAT TRUST ATTACK THAT YOU'RE DESCRIBING.
SO THIS SORT OF PIECEMEAL, NOT ENTIRE FORKLIFT REPLACEMENT IS INCREDIBLY VALUABLE.
AND AMAZON NEEDED TO HAVE THAT.
THAT WAS AN ECONOMICALLY VALUABLE PLACE WHERE DNSSEC WOULD HAVE HELPED THEM.
IT'S NOT CLEAR THAT THAT'S BEEN UNDERSTOOD TO BE A SOLUTION FOR THEM.
BUT THOSE ISPS WOULD HAVE CAUGHT AND RESOLVED THAT PROBLEM WITH DNSSEC.
>>JOHAN IHREN: WELL, I FULLY AGREE WITH THIS EXAMPLE.
AND IF WE LOOK AT THIS FROM A SLIGHTLY DIFFERENT PERSPECTIVE AND WE CHANGE -- THIS IS GOING OFF ON A LIMB HERE -- IF WE CHANGE THE STATEMENT OF DNSSEC PROVIDING SECURITY, AND IF WE DO DNSSEC, WE WILL SUDDENLY BE SECURE, AND WE INSTEAD MOVE AWAY AND SAY THAT WHAT WE'RE DOING HERE IS WE INCREASE THE TRUST IN THE SYSTEM, IT WOULD BE IMPOSSIBLE FOR PEOPLE TO TRUST WHERE THEY ARE GOING, WHETHER BROWSING ON THE WEB OR WHATEVER.
AND DNSSEC PROVIDES THIS TOOL TO BE ABLE TO ENSURE THAT WHEREVER I GOT WAS EXACTLY WHERE I WANTED TO GO.
AND THAT IS PROBABLY GOOD FOR THE INTERNET USAGE IN GENERAL.
>>DOUG BARTON: OKAY.
AT THAT POINT, I THINK WE SHOULD INSERT A PAUSE INTO THIS PART OF THE DISCUSSION.
I'D LIKE TO -- BEFORE YOU SPEAK, SIR, I'D LIKE TO MAKE A COUPLE OF PROCEDURAL POINTS.
ONE IS THAT I'M SURE THAT THE PART OF THE PRESENTATION THIS MORNING THAT YOU'RE MOST INTERESTED IN IS THE COFFEE BREAK.
AND I WOULD LIKE TO POINT OUT THAT WE WILL BE HAVING THAT AT THE CONCLUSION OF THIS PANEL.
AND WE WILL BE MOVING THE PRESENTATION BY MR. KANE TO AFTER THE COFFEE BREAK.
AND I WOULD LIKE TO EXERCISE MODERATOR'S PRIVILEGE TO ANSWER SABINE'S QUESTION IN A SLIGHTLY DIFFERENT WAY, WHICH IS TO SAY THAT THERE'S TWO ASPECTS OF THE COST THAT I THINK ARE IMPORTANT TO KEEP IN MIND.
ONE IS THAT, SIMILAR TO THE WAY THAT WE'RE SEEING NEW HARDWARE WITH IPV6 CAPABILITIES REPLACE OLDER HARDWARE IN JUST THE NORMAL MAINTENANCE PROCEDURES ON MOST NETWORKS, THAT THE NAME SERVER SOFTWARE IS GOING TO UNDERGO SIMILAR TRANSITION OVER TIME, AND THAT NOT ALL OF THE COST OF IMPLEMENTING DNSSEC WILL BE BORNE AS A ONE-TIME VALUE-ADDED COST, IF YOU WILL.
THE OTHER ASPECT OF THIS THAT I THINK IS IMPORTANT TO KEEP IN MIND IS THAT THE COST OF NOT DEPLOYING DNSSEC ARE SIGNIFICANTLY HIGHER THAN THE COST OF DEPLOYING IT WOULD BE. AND ALL YOU WOULD NEED IS ONE SIMPLE SPOOF OF SOMETHING LIKE WINDOWS UPDATE.COM THAT WOULD, TOMORROW, CONVINCE THE WORLD THAT DNSSEC IS AN ABSOLUTELY NECESSARY ELEMENT THAT WE NEED TO INCLUDE IN THE NETWORK.
SO IF WE COULD, SIR, I'D LIKE YOU TO ASK YOUR QUESTION AND WE'LL MAKE THIS THE LAST QUESTION FROM THE AUDIENCE. AND THEN WE'LL MOVE ON FROM THERE. THANK YOU.
>>DR. GOVIND: THANK YOU. I'M DR. GOVIND. WE HAVE RECENTLY LAUNCHED DOT IN REGISTRY IN INDIA. MY QUESTION IS TO MR. RAM AND MR. NEVES HERE. THE TRAINING ASPECTS AND REMNANT ASPECTS IN THE COUNTRY FOR DNSSEC, BUT WHAT ARE THE COST IMPLICATIONS BECAUSE WE HAVE A LOT OF COST INTO THAT. AND WITH THAT INDUSTRY, ONE HAS TO IMPLEMENT, HAS THERE BEEN ANY COST/BENEFIT ANALYSIS BEEN CARRIED OUT BY .BR AND THE TEST BED AND HOW ARE THE BENEFITS GOING TO INURE TO THE REGISTRANTS AND THE ISPS IN THIS?
>>FREDERICO NEVES: WE EXPECT THIS TO BRING A CHAIN OF TRUST INSIDE BR, ESPECIALLY FOR THE INITIAL ZONES, THE TOP-LEVEL ZONE FOR BR AND (INAUDIBLE) BR. WE HAVE IN BRAZIL A VERY GOOD EXPERIENCE OF PROVIDING TAXPAYERS TO PROVE THAT THEY -- THE TAX PAYMENT TO THE MINISTER OF FINANCE USING INTERNET APPLICATIONS. I THINK WE HAVE ONE OF THE BIGGEST PENETRATIONS IN THE WORLD, NEARING 100 PERCENT USING -- PROVIDING TAX INFORMATION THROUGH INTERNET.
SO THIS DNSSEC IN THIS ARENA COULD BE A GOOD HELP TO -- TO -- LIKE TRYING TO CLOSE A WEAK LINK IN THE SECURITY AREA.
AND THE COST IN DEPLOYING IT, AS I SAID BEFORE, WHEN WE UPGRADED OUR DNS INFRASTRUCTURE, WE ALREADY TOOK THE MEASURES TO INSURE THAT IT WILL HAVE SUFFICIENT ROOM TO HAVE ZONES WHEN WE GET TO OUR ZONE ASSIGNMENT WITH FIVE OR SIX TIMES THE SIZE THEY HAVE TODAY.
SO IT'S -- WE HAVE ALREADY SPENT THIS MONEY UPGRADING THIS IN THE LAST COUPLE OF YEARS -- LAST YEAR. SO THERE WILL BE -- BESIDES THE DEVELOPMENT COST OF THE REGISTRY SOFTWARE THAT ARE NOT ALL THAT BIG, THIS IS THE ONLY COST THAT WE WILL HAVE.
>>RAM MOHAN: I'D LIKE TO POINT OUT THAT, WITH DNSSEC AND WHAT IT'S TRYING TO SOLVE, THAT WE SHOULD LOOK AT AND PARTICULARLY BOTH GTLDS AND CCTLDS, WE SHOULD LOOK AT THE PROBLEM WITH TWO TYPES OF ANALYSIS. ONE IS THE CONVENTIONAL COST/BENEFIT ANALYSIS, BUT I'D ALSO SUGGEST TO ALL OF YOU, AND I THINK THIS IS SOMETHING THAT IN THE PANEL WE HAVE TAKEN FOR GRANTED, BUT THE OTHER ANALYSIS THAT WE SHOULD DO IS A RISK/BENEFIT ANALYSIS, BECAUSE THERE IS A SIGNIFICANT RISK HERE. AND SOMETIMES THAT OVERRIDES SOME OF THE EARLY COST REQUIRED, CAPITAL EXPENSES REQUIRED TO GET THIS GOING.
SO TO SPECIFICALLY ANSWER YOUR QUESTION, DR. GOVIND, I DON'T BELIEVE A GENERALLY AVAILABLE MODEL OF COST/BENEFIT FOR DNSSEC -- I HAVE NOT SEEN ONE. HOWEVER, I HAVE SEEN ENOUGH EXAMPLES OF RISKS AND EXAMPLES OF WHAT HAPPENS IF YOU HAVE DNSSEC AND WHAT THE BENEFIT OF THAT IS. AND I SUGGEST THAT BOTH OF THOSE ANALYSES SHOULD BE DONE IN PARALLEL.
>>DOUG BARTON: THANK YOU ALL VERY MUCH. AND WE'D LIKE TO THANK ALL THE MEMBERS OF THE PANEL FOR THEIR EXCELLENT PRESENTATIONS AND INSIGHT ON THIS TOPIC, AND THE FINE MEMBERS OF OUR AUDIENCE WHO PROVIDED EXCELLENT QUESTIONS AS WELL.
AND TO WRAP UP THIS MORNING'S SESSIONS, WE HAVE A WORD FROM OUR HOST.
>>STEVE CROCKER: TURN THE MIKE AROUND THIS WAY. I'M STEVE CROCKER. LET ME ADD MY WELCOME.
WE'RE GOING TO TAKE A BREAK NOW. MARILYN CADE I THINK IS CHAIRING THE WSIS MEETING IN THIS ROOM AT 1:00, ASKED ME TO MENTION THAT LUNCH WILL BE SERVED AT 12:00 INSTEAD OF, I GUESS IT WAS SET UP FOR LATER, ON THE 12TH FLOOR.
AND WE WILL END THIS SESSION PROMPTLY, IF NOT SLIGHTLY EARLIER, IN ORDER TO MAKE IT EASY FOR EVERYBODY TO GET UP TO LUNCH.
SO TAKE A QUICK BREAK NOW, COME ON BACK AND THEN WE'LL HAVE THE LAST PART OF THIS SESSION.
.THANKS
(BREAK)






>>PAT KANE: WELCOME BACK. MY NAME IS PAT CANE, THE COM/NET DATA MANAGER FOR VERISIGN , AND WHAT I WANTED TO DO IS COVER A BUSINESS -- YOU CANNOT HEAR? , I WANTED TO COVER BUSINESS CASE FOR DNSSEC.

THIS MORNING WE HEARD PRESENTATIONS FROM THE TECHNICAL COMMUNITY AND WHAT WE DISCOVERED OR WHAT WE KNOW IS THAT THE RFCS HAVE BEEN ACCOMPLISHED FOR DNSSEC. THEY'VE BEEN OUT FOR A COUPLE WEEK, THREE RFCS.
WE HEARD FROM DIFFERENT REGISTRIES ABOUT THE INDIVIDUAL DEPLOYMENT PLANS THAT THEY HAVE FOR THEIR DOMAINS.
WE KNOW THAT WHAT'S COMING UP IN TERMS OF RFCS FOR EPP, FOR PROVISIONING DNSSEC, EPP, AND THERE IS AN IETF OPERATIONAL PRACTICES THAT'S BEING WORKED ON RIGHT NOW.
SO WHAT IS NEEDED IN DNSSEC FOR FROM A REGISTRY REGISTRAR GUIDELINE? WE NEED GUIDELINES AROUND POLICY, AROUND PROVISIONING. WE NEED TO HAVE A KNOWLEDGE BASE THAT WE CAN SHARE ACROSS THE COMMUNITY AROUND DNSSEC.
WHAT ARE THE CUSTOMER SUPPORT ISSUES THAT WE FACE, AND WHAT ARE THE DIAGNOSTIC TOOLS THAT WE CAN DEVELOP TO HELP THE ENTIRE ECOSYSTEM.
WE CERTAINLY NEED COMMUNITY COOPERATION. WE NEED TO WORK TOGETHER AS REGISTRIES AND REGISTRARS TO ADVANCE IT, AND WHAT DON'T WE HAVE? IS WE DON'T HAVE A REFERENCE EVENT.
IN 1989, THE EXXON VALDEZ FOUND ITSELF PARKED ON A REEF, AND WITHIN A YEAR OF THAT EVENT, THE UNITED STATES GOVERNMENT PASSED THE OIL POLLUTION ACT. IT CHANGED THE WAY OIL SPILLS WERE TREATED IN THE UNITED STATES.
WE DON'T HAVE THAT EVENT TO RALLY AROUND FOR DNSSEC. WE DON'T HAVE SOMETHING THAT SAYS IT'S ON THE FRONT PAGE OF THE NEWSPAPER, IT'S ON CNN.COM SUCH THAT WE CAN MAKE THINGS HAPPEN IN THE PUBLIC.
THAT'S A GOOD THING AND A BAD THING. THE GOOD THING IS WE DON'T HAVE THE REFERENCE EVENT; THE BAD THING IS WE DON'T HAVE THE MOTIVATION THROUGH THE ENTIRE COMMUNITY.
SO WHEN YOU DON'T HAVE A REFERENCE EVENT AND YOU HAVE AN IMPACT ACROSS A COMPLETE INFRASTRUCTURE SUCH AS THIS, IT DOESN'T SHOW UP WELL BUT IT SHOWS THE REGISTRIES, THE REGISTRARS, ISPS, ET CETERA, YOU'VE GOT A MODIFICATION THAT HAS TO TAKE PLACE IN ALL THE AREAS OF THE ECOSYSTEM FOR DNSSEC.
SO I SAID, IT CHANGES EVERY PART OF THE DNS ECOLOGY. IT ADDS COMPLEXITY TO RESOLUTION. WHAT HAPPENS TO AN END USER WHO IS SITTING IN THEIR HOME, THEY HAVE TWO SEPARATE BROWSER APPLICATIONS, ONE IS DNSSEC AWARE, ONE IS NOT. THEY GET A DIFFERENT RESPONSE TO EACH APPLICATION. THERE'S CONFUSION. WHO DO THEY CALL AND THEY FINALLY FIGURE OUT WHO THEY ARE SUPPOSED TO CALL HOW DOES THAT GET RESOLVED AND ANSWERED FOR THE INDIVIDUAL END USER. WHAT SHOULD BE DONE WITH LARGE ZONE FILES. WE KNOW DNSSEC COULD TRIPLE THE SIZE OF ZONE FILES. A FILE HAS ABOUT 140 MILLION RECORDS THAT BECOMES 120 MILLION RECORD ZONE FILE. THERE'S A LOT OF IMPACT TO THAT WE DON'T UNDERSTAND YET. AND WE DON'T KNOW THE TRUE BEHAVIOR IN ROLLING OUT DNSSEC. WE NEED TO TAKE IT SLOW, MOVE IT FORWARD AND GET PILOTS THAT ARE WIDELY PARTICIPATED IN. RAM MOHAN SUGGESTED EARLIER WE HAD ISSUES AROUND GETTING THE WORD OUT TO PARTICIPATE IN PILOTS. IF WE DON'T AS A COMMUNITY PARTICIPATE IN THESE PILOTS AN!
D LET THE TECHNICAL COMMUNITY KNOW WHAT IT IS THAT WE NEED TO HAVE SOLVED, THEN WE'RE NOT GOING TO ADVANCE VERY QUICKLY WITH THE DEPLOYMENT OF DNSSEC.
SO THINGS TO CONSIDER. REGISTRIES AND REGISTRARS HAVE TO BALANCE MARKET DEMAND WITH TECHNICAL NEED. AS FAR AS MARKET RESEARCH, THERE'S NO PROOF TODAY THAT THERE'S A MARKET FOR DNSSEC. THE REGISTRARS ARE THE ONES THAT HAVE TO PROVISION THIS ARE GOING TO PRIORITIZE REVENUE-GENERATING PROJECTS OVER SOMETHING THAT THEY CAN'T MAKE MONEY ON, THAT THEY CAN'T GET MONEY BACK ON.
WE STILL DON'T HAVE A LOT OF APPLICATIONS THAT ARE AVAILABLE TODAY TO MOVE FORWARD WITH DNSSEC DEPLOYMENT. WE NEED TO EVANGELIZE SUPPORT IN THE COMMUNITY. AND HOW DO WE LEARN TOGETHER AS A COMMUNITY SUCH THAT WE CAN OVERCOME THE NONTECHNICAL PRESSURES WHICH ARE WHERE IS THE REVENUE.
IN THE TECHNICAL COMMUNITY, WE STILL HAVE TO WORRY ABOUT ITEMS SUCH AS WALKING THE ZONE WHICH WE HAD A BRIEF DISCUSSION ABOUT EARLIER TODAY. FOR GTLD, IS IT REALLY AN ISSUE? WITH CCTLDS, IT CLEARLY IS WITH SOME OF THEM. THE REGISTRY DECISION POINT WILL COME DOWN TO BALANCING DEMAND AND THE TECHNICAL NEED AND THE REGISTRARS WILL COME DOWN TO COST AND COMPLEXITY VERSUS REVENUE. AND WHEN I TALK ABOUT COMPLEXITY, THE REGISTRIES ARE MOVING FORWARD WITH DNSSEC DEPLOYMENT, NEED TO MAKE IT SIMPLE OR EASY FOR THE REGISTRARS TO DEPLOY AND PROVISION DNSSEC FOR SEVERAL DIFFERENT REGISTRIES. REGISTRIES SHARE BASICALLY THE SAME SET OF CUSTOMERS IN THE REGISTRARS. WE NEED TO WORK TOGETHER TO MAKE IT EASY FOR THEM TO DEPLOY DNSSEC.
SO IN LIEU OF THE EXXON VALDEZ, WE NEED TO UTILIZE THE PILOTS THAT ARE AVAILABLE TO US. SEVERAL WERE MENTIONED THIS MORNING. VERISIGN OPERATES TWO DIFFERENT PILOTS RIGHT NOW. BUT WE DON'T HAVE ANY PILOTS TODAY AROUND PROVISIONING. IT'S ALL AROUND THE USE OF DNSSEC WITHIN THE ZONE FILES. AND AGAIN NO PARTICIPATION MEANS THAT IT WILL ADVANCE VERY SLOWLY.
AS A COMMUNITY, WE NEED TO PARTICIPATE AND ADVANCE FORUMS AROUND DNSSEC. TO DATE, MOST OF THOSE FORUMS HAVE BEEN AROUND THE STANDARDS DEVELOPMENT WORKING THROUGH THE IETF. WHAT WE NEED TO GET IS THE REGISTRIES, REGISTRARS, APPLICATION DEVELOPERS, OS PROVIDERS TO GET TOGETHER TO SOLVE THE DEPLOYMENT ISSUES.
AND WE ALSO NEED TO DEVELOP A LIVING BEST-PRACTICES APPROACH SO THAT WE CAN SHARE THAT KNOWLEDGE THROUGHOUT THE COMMUNITY.
WE NEED TO ENERGIZE THE COMMUNITY TO MAKE THIS HAPPEN OR IT WON'T.

AND LASTLY, WE NEED TO FIGURE OUT HOW TO ESTABLISH A FRAMEWORK SO THAT EVERYONE IN THE ECOSYSTEM CAN PARTICIPATE, COORDINATE THEIR EFFORTS; AGAIN, SIMPLIFY THE REGISTRY DEPLOYMENT AND SEEK SOME KIND OF COMMUNITY FUNDING ARRANGEMENT THAT SUPPORTS THE REGISTRARS. THE REGISTRARS ARE THE ONES THAT HAVE TO MAKE THIS HAPPEN WITH THE REGISTRANTS.
WORKING WITH THE REGISTRIES, WE CAN MAKE THOSE HAPPEN WITH THE TLDS. SABINE ASKED A QUESTION EARLIER ABOUT WHAT THE COST IS. THE COST TO THE REGISTRIES, WE BELIEVE IN THE FIRST YEAR IN COM AND NET IT WILL TAKE US $5 MILLION TO DEPLOY DNSSEC. THAT'S AT THE REGISTRY. THE REGISTRARS ARE GOING TO HAVE COSTS BEYOND THAT THAT WE NEED TO HELP THEM WITH.
SO WHAT HAS VERISIGN BEEN WORKING ON? WE STARTED TO WORK THROUGH A VERY LOOSE CONSORTIUM AROUND APPLICATIONS AND SERVICE PROVIDERS. WE WANT TO EVANGELIZE WITH OUR CUSTOMERS AND PEOPLE WE SEE AROUND THE GLOBAL THAT DNSSEC IS HERE, IT'S COMING BUT TO GET THE ADVANTAGE OF WHAT THE TECHNICAL COMMUNITY HAS BEEN SPENDING TEN YEARS ON, WE NEED TO MAKE IT HAPPEN. IT'S NOT THERE YET. WE STILL NEED TO ADVANCE THAT BALL.
WE'VE BEEN RUNNING PILOTS. WE HAVE AN OLD PILOT THAT WAS AN OPT-IN PILOT THAT THE TECHNICAL COMMUNITY IS NO LONGER GOING THAT DIRECTION, SO THAT HAS BEEN A SUNSETTED PILOT. BUT WE STILL HAVE TWO OTHER PILOTS. ONE IS A LOOK-ASIDE VALIDATION PILOT. WE INVITE YOU TO COME PARTICIPATE IN THAT AS WELL. THE SAME THINGS THAT RAM POINTED OUT EARLIER, THERE'S SMALL PARTICIPATION IN THESE PILOTS TODAY.
SO WE NEED TO EVANGELIZE THE USE OF THE PILOTS. AND WE HAVE A SECOND AROUND FOCUSED AROUND DOT NET THAT YOU CAN SIGN UP FOR AND PARTICIPATE IN AS WELL. THE PILOTS WILL HELP DRIVE ADOPTION, BECAUSE WHAT WE'LL BE ABLE TO DO IS IDENTIFY THE ISSUES THAT WE DON'T KNOW ABOUT. WE NEED TO MOVE SLOWLY AND MAKE THESE -- AND MAKE IT AVAILABLE TO EVERYONE IN THE ECOSYSTEM SUCH THAT WE CAN DEPLOY IT.
THANK YOU.
ANY QUESTIONS?
THANK YOU VERY MUCH.
>>ED LEWIS: HELLO. MY NAME IS ED LEWIS. I'M GOING TO TALK ABOUT DNSSEC MEETS EPP. AND THIS TITLE WAS INSPIRED BY THE MONSTER MODIFIES WHERE YOU HAVE REALLY LARGE UGLY MONSTER MEETS A SMALL LITTLE BUNNY.
I'M GOING TO BREAK THE PRESENTATION -- I'M GOING TO SET UP THE DEMONSTRATION FIRST BY TALKING ABOUT TWO TOPICS. ONE IS WHAT DOES DNSSEC DO TO REGISTRIES? WE'VE TALKED ABOUT DNSSEC IN THE LARGE AND HOW IT EFFECTS THE DNS. I'M GOING TO KEY ON WHAT IT MEANS TO A REGISTRY AND TALK ABOUT THAT APPLICATION.
AND I'M ALSO GOING TO TALK ABOUT WHY ARE WE BOTHERING EXTENDING EPP FOR DNSSEC. AND THEN AFTER THAT, A SHORT DEMO TO SHOW THAT THIS IS ACTUALLY SOMETHING HERE THAT WORKS TECHNICALLY.
IN A NUTSHELL, IN DNSSEC, WHAT HAPPENS IS I LOOK FOR INFORMATION AND, FOR EXAMPLE, I WANT THE WEB PAGE FOR THE COMPANY I WORK FOR. AND I WILL GET THE KIND OF INFORMATION THAT'S GOING TO BE UP ON THE SCREEN RIGHT NOW. WHAT DNSSEC IS GOING TO DO TO ME FIRST IS IT'S GOING TO COME BACK WITH SOME PROTECTION. IT'S GOING TO HAVE A SIGNATURE WHICH SAYS THIS REALLY IS -- IT WILL DEMONSTRATE THAT THIS REALLY IS THE DATA YOU WANT.
BUT TO MAKE THAT WORK, I NEED TO ALSO HAVE A KEY THAT HELPS ME PROVE T THE KEY WILL GO AND UNLOCK THE SIGNATURE TO SAY THAT THIS IS THE RIGHT DATA.
NOW, THIS REALLY DOESN'T SOLVE A LOT BECAUSE NOW I NEED TO KNOW, IS THIS KEY THE RIGHT THING?
SO WHY SHOULD I BELIEVE THIS KEY IS THE RIGHT THING? WHERE DO I GET THE PROOF FOR THAT? BUT MOST IMPORTANTLY, HOW DO I DO IT SCALABLY? HOW DO I MAKE THIS WORK FOR THE SIZE OF THE DNS IT IS TODAY? THE ANSWER IN DNSSEC IS SOMETHING CALLED A DS RECORD WHICH WE WON'T DRIVE INTO BUT IT IS WHAT REGISTRIES HAVE TO WORRY ABOUT WHEN IT COMES TO REGISTRATION FOR DNSSEC.
NOW, TO GIVE YOU A SCHEMATIC PICTURE OF THIS, THE DNS TODAY AS WE KNOW IT TODAY HAS NS RECORDS. NS RECORDS FORM A TREE. THEY POINT FROM SERVER TO SERVER TO SAY HERE IS THE ROOT ZONE, HERE ARE THE TLD SERVERS. THE TLD SERVERS SAY HERE ARE ALL THE OTHER SERVERS WE NEED. THEY MAYBE SUBDELEGATIONS AND SO ON BUT THE NS RECORDS CREATE A CHAIN FOR DNSSEC, WE ADD ANOTHER SET OF CHAIN WHICH ARE THE DS RECORDS POINT TO KEYS, AND THIS IS NOW A PARALLEL TREE. THIS TREE IS GOING TO LOOK JUST LIKE THE NS TREE, IT'S JUST ANOTHER TREE.
TO LOOK AT THE NS AND DS TREE WHICH IS THE NS AND DNS DS SEC DELEGATION, THEY CHAIN THE KEY TO THE SYSTEM. SO THEY LOOK THE SAME BUT THERE ARE NOTICEABLE DIFFERENCES. DS RECORDS HAVE TO CHANGE MORE OFTEN THAN NS RECORDS FOR DIFFERENT REASONS RELATED TO CRYPTOGRAPHY AND THE SCIENCE BEHIND ALL OF THAT.
ALSO, CHANGING DS RECORDS HAS TO BE DONE IN A VERY GRACEFUL MANNER. I WANT TO BE ABLE TO HAVE A DS RECORD IN EFFECT TODAY AND ANOTHER ONE TOMORROW BUT I WANT TO CHANGE BETWEEN THE TWO OF THEM IN A VERY GRACEFUL MANNER. IF I HAVE TO CHANGE MY NAME SERVERS THERE MAY HAVE BEEN A NETWORK OUTAGE ANYWAY OR SOME PROBLEM, I CAN CHANGE MY NAME SERVERS.
ALSO, THE DS RECORDS IMPLY MORE SECURITY. I'M NOT GOING TO IDENTIFY EXACTLY WHAT THAT MEANS, BUT NS RECORDS HAVE JUST BEEN TAKEN AS PART OF THE RECORDS. THE DS RECORDS MEAN NOW YOU'RE SAFE, IN QUOTES.
DNSSEC REGISTRIES, WHAT DOES IT MEAN TO US.
OUR BUSINESS HERE IS TO HANDLE DS RECORDS. WE WANT PEOPLE TO HANDLE DS RECORDS AS PART OF THEIR DOMAIN NAME REGISTRATION.
WE MAY ALSO -- SOME REGISTRIES MAY WANT TO USE THE DNSKEY WHICH IS ANOTHER RECORD I REFERRED TO BACK A FEW SLIDES. NOT ALL REGISTRIES BELIEVE THEY NEED TO HAVE THAT, SOME WANT TO HAVE THAT AND THERE IS STILL SOME ONGOING TESTING TO SEE WHETHER OR NOT THE DNSKEY IS HELPFUL HERE.
BESIDES TRYING TO REGISTER DS RECORDS, IF I WANT TO REGISTER THEM I HAVE TO TAKE THE INFORMATION FROM THE DS RECORD AND PUT IT IN A REGISTRY SO THERE'S NO QUESTION THAT THE INFORMATION FLOW HAS TO BE DEFINED BY WHAT A DS RECORD IS BUT WE'VE ALSO IDENTIFIED ONE OTHER ISSUE BEYOND THE DS RECORD ITSELF, AND THAT IS WE DON'T WANT TO SECURE THE DS RECORD FOR TOO LONG A PERIOD OF TIME. THERE ARE VULNERABILITIES TO THE REGISTRANT IF THE DS RECORD HANGS AROUND TOO LONG. SO WE'RE GOING TO LET THE REGISTRANT TELL US, MAKE SURE WHATEVER YOU SIGN FOR THIS DS RECORD, IT DOESN'T LAST MORE THAN A MONTH SO THERE WILL BE SOME NUMBER WE HAVE TO PASS ALONG WITH THAT.
NOW, THE BUILDING BLOCK UPON WHICH WE'RE GOING TO REGISTER DNSSEC WILL BE EPP, OR A LOT OF US WOULD LIKE IT TO BE EPP. IN OUR BUSINESS CASE IT MAKES SENSE BECAUSE WE ARE RUNNING A GTLD UNDER THE ICANN AUSPICES. EPP IS THE PREFERRED INTERFACE.
EXTENSIBLE PROVISIONING PROTOCOL IS THE NAME OF THE PROTOCOL. IT'S A STANDARD PLATFORM, IT'S SO WE CAN HAVE REGISTRARS AND REGISTRIES INTERMIX THE COMMUNICATION. THEY CAN WORK WITH BIZ, COM/NET, WHATEVER IT IS WITHOUT CHANGING THAT LEVEL OF THEIR SOFTWARE. THERE MAY BE DIFFERENT BUSINESS CASES BUT AT LEAST THEY CAN COMMUNICATE BACK AND FORTH.
ALSO, EPP IS BUILT TO BE EXTENSIBLE. WE WANTED TO BUILD THE ORIGINAL EPP TO ADD ON NEW SERVICES AS WE GO ALONG. BESIDES THE BASIC COMMUNICATION IT CAN DO MORE FEATURES AND SERVICES ABOVE THAT.
THE REASON WHY THIS IS GOOD FOR US, FOR REGISTRIES, WE GET MORE EXPOSURE. IT LETS US HAVE A LARGER CLIENT BASE. OUR REGISTRAR NUMBERS ARE GREATER.
FOR THE REGISTRARS OUT THERE, THEY NOW HAVE A PLATFORM WHICH HELPS THE COMMUNICATION PROBLEMS GO DOWN A LITTLE BIT.
IT'S NOT A COMPLETE SOLUTION BUT IT DOES GO DOWN A LITTLE BIT.
TO PUT THIS ALL INTO A SCHEMATIC DIAGRAM, THE BUSINESS OF THE ENTIRE INTERNET IS WHAT I HAVE ON THE BOTTOM OF THE SCREEN WHICH IS GETTING A REGISTRANT OR THE CUSTOMER OR THE PERSON DOING BUSINESS ON THE INTERNET, HAVING THEM PUT UP A, IN THIS CASE, A WEB INTERFACE THAT A CUSTOMER CAN COME TO. TO MAKE THAT HAPPEN, THE DNS IS INVOLVED, AND THIS IS WHERE DNSSEC PLAYS A ROLE. THE INTERNET USER WILL GO OFF AND WALK THROUGH THE DNS, GET THE RESULTS AND FIND THE WEB SERVER.
THE DNS SERVERS -- I DON'T SHOW THE ROOT SERVERS BEING FULFILLED HERE. I'LL LEAVE THAT AS A MYSTERY. THE DNS OPERATOR FOR THE REGISTRANT MAYBE A CONTRACTOR, WHO KNOWS, AND THE TLD REGISTRY ARE GOING TO BE THE ONES POPULATING THE DNS SERVERS.
WHERE EPP FITS IN THE MODEL RIGHT NOW IS AT THIS TOP LEVEL WHERE THE REGISTRAR TALKS TO THE TLD REGISTRY THROUGH EPP, EPP INTERFACE, OR SOMETHING SIMILAR TO IT RIGHT NOW IN SOME CASES.
IF YOU NOTICE IN THE PICTURE RIGHT NOW I DON'T HAVE ALL THE LINES PUT TOGETHER BECAUSE WE HAVEN'T TALKED ABOUT THE ENTIRE PROBLEM OVER HERE, WHICH IS HOW DO WE GET BETWEEN THE REGISTRANT, THE DNS OPERATOR, THE RESELLERS AND THE REGISTRARS. THAT'S A MARKET WHICH IS STILL DIVIDED. IT'S NOT NECESSARILY GOING TO GO ONE WAY OR THE OTHER BUT IT'S A MARKET THAT'S STILL FORMING AND ONE POSSIBILITY IS THAT EPP MIGHT ACTUALLY BE HELPFUL IN THAT CASE, TOO. THAT'S A POSSIBLE EXTENSION OF EPP IN THE FUTURE.
IN FACT, IF YOU WERE TO FORGET THAT WE'RE TALKING ABOUT DOMAIN NAMES AND GO TO THE ADDRESS SPACE, THE RIRS, THE REGIONAL INTERNET REGISTRIES THEY MAY BE ABLE TO MAKE USE OF A TOPOGRAPHY SOMETHING LIKE THIS SO IT GOES BEYOND THE DOMAIN NAME REGISTRATION.
SO WE HAVE EPP, WE HAVE DNSSEC. WHAT HAPPENED WHEN THEY MEET? THE PRIMARY GOAL HERE IS TO USE EPP TO CARRY THE DNSSEC INFORMATION ACROSS THE INTERFACES THAT WE DEFINE BETWEEN REGISTRAR AND THE REGISTRY.
WHY EPP? BECAUSE IT'S AN EXISTING SERVICE FRAMEWORK. IT MINIMIZES SOFTWARE INVESTMENT AND IT CAN HELP US DEVELOP WHATEVER MARKETS WE NEED ABOVE THAT.
NOW, I'M GOING TO MOVE QUICKLY INTO THE PROTOTYPE. THE PROTOTYPE IS ACTUALLY PRETTY QUICK. BUT THERE WAS SOME WORDS OF WISDOM ON SUNDAY IN A CARTOON WHICH EXPLAINS PROTOTYPES. IN THIS CASE HERE, A PROTOTYPE IS BEING GIVEN OF A NEW PAIR OF HEADPHONES, AND IN THE FIRST TWO SLIDES SETS UP THE PROTOTYPE. IN THE LAST BOTTOM PART, WHICH YOU DON'T HAVE THIS PRINTED OUT, THE -- ONE OF THE PEOPLE TRIES THE PROTOTYPE AND REALIZES IF I PRETEND I DON'T HEAR THE STUFF, THE PROTOTYPE WORKS. THAT'S THE POINT OF OUR PROTOTYPE.
WHAT I'M GOING TO SHOW YOU ACTUALLY WORKS BUT IT DOESN'T HAVE A LOT OF BUMPERS. IT'S NOT REALLY COMPLETE BUT IT'S GENERALLY THE IDEA WE WANT TO SEE INTO THE FUTURE.
SO WITH THAT I'M GOING TO MOVE TO THE DEMO. I'M GOING TO HAVE A FEW WINDOWS I'M GOING TO POP UP ON THE SCREEN. I'M GOING TO SHOW A TLD NAME SERVER WHICH IS WHAT, FOR EXAMPLE, .BIZ IS GOING TO BE OUT THERE. I'M GOING TO USE THE EXAMPLE .TLD IN THIS CASE.
I'M GOING TO HAVE THE REGISTRANT WORKING AWAY AT DOING DNSSEC IN THEIR ZONE ON THE OTHER SIDE AND IN BETWEEN I'M GOING TO HAVE THE EPP CLIENT TO SERVER AND THEN AN UPDATER FOR THE DNS. AND WHAT'S MISSING IN THIS ENTIRE EXAMPLE IS A DATABASE. AND THAT'S WHERE THE PROTOTYPE IS FALLING APART.
BUT TO HELP ORIENT YOU IN WHAT YOU'RE GOING TO SEE ON THE SCREEN, BECAUSE, FRANKLY, THE SCREEN RESOLUTION IS SMALLER THAN I'M EXPECTING SO IT WILL BE HARD TO SEE THE ACTUAL STUFF HAPPEN. WE'RE GOING TO SEE THESE FIVE WINDOWS, BASICALLY IN THIS ORIENTATION BUT I WILL MOVE THEM AROUND BECAUSE I FOUND THEY DON'T WORK TOO WELL.
I HAVE ON THE TOP EPP RUNNING BETWEEN THE TWO TOP WINDOWS, WHICH IS BASICALLY THE STAR EVENT HERE. THESE TWO TOP WINDOWS ARE TALKING TO THE SERVER AND CLIENT THROUGH EPP CARRYING DNSSEC INFORMATION THROUGH THEM.
I'M GOING TO DO CUT AND PASTE THROUGH THE WORK WINDOW WHERE I'LL BE DOING ALL THE TYPING ON THE RIGHT -- LEFT-HAND SIDE, SORRY. I'VE NEVER GOTTEN MY LEFT AND RIGHT CORRECT IN MY LIFE. LEFT-HAND SIDE IS WHERE I'M GOING TO BE WORKING AS A CUSTOMER AND I'M GOING TO PUT INFORMATION IN. ON THE RIGHT-HAND SIDE IS WHAT WILL HAPPEN WITH THE REGISTRY AND I'LL BE USING A LOG FILE TO SAY HERE ARE THE UPDATES COMING OUT OF THE EPP SERVER, AND HERE ARE THE UPDATES THAT THE NAME SERVER. SO THE NAME SERVER IS ACTUALLY GOING TO GET UPDATED AS I'M RUNNING THE DEMO.
SO I'M GOING TO GO TO MY LITTLE FICTIONAL WORLD HERE, I APOLOGIZE, THIS IS ABOUT THE BEST I CAN DO. AND I'M GOING TO START UP HERE, I'M GOING TO START MY NAME SERVER.
IN THIS WINDOW JUST ABOVE THAT, I'M GOING TO START UP MY UPDATING CLIENT.
WHAT WILL HAPPEN, EVERY 15 SECONDS, IT WILL TRY TO UPDATE THE DNS.
AND UP HERE, THIS IS MY EPP SERVER.
SO OVER HERE I'M GOING TO -- AND THESE THREE WINDOWS REPRESENT WHAT A REGISTRY WOULD HAVE.
THE TOP WINDOW IS MY FRONT DOOR TO THE REGISTRARS.
THE MIDDLE OF IT IS WHAT EXTRACTS THE DNS CHANGES OUT OF MY DATABASE.
AND THE BOTTOM IS THE DNS SERVER, THE SERVICE I'M WORRIED ABOUT PROVIDING TO MY CUSTOMERS.
NOW, THIS WINDOW UP ON TOP HERE IS GOING TO REPRESENT WHAT HAPPENS AT THE REGISTRAR.
THIS IS HOW THE REGISTRAR WOULD COMMUNICATE TO THE REGISTRY.
AND THERE'S A BUNCH OF MUMBO JUMBO HERE.
I'M GOING TO LOG IN.
AND THERE'S A LOG-IN USER ID AND PASSWORD.
AND WHAT WILL HAPPEN IS YOU'LL JUST SEE SOME STUFF FLY BOTHER.
IT'S NOT IMPORTANT WHAT'S HAPPENING HERE.
BUT THE REGISTRY NOW HAS AN OPEN CONNECTION.
DOWN HERE I HAVE A REGISTRANT WHO IS BUILDING THEIR BUSINESS RIGHT NOW.
AND WHAT THEY HAVE IS A ZONE FILE, WHICH IS UP HERE, WHICH IS PROBABLY, FOR THE MOST PART, UNINTELLIGIBLE.
BASICALLY, WHAT I WANT TO POINT OUT HERE IS THAT I HAVE NAME SERVER RECORDS, WHICH ARE THE RECORDS THAT YOU HAVE TO HAVE FOR DNS TO WORK.
SO THIS PERSON WOULD GO OFF TO THE REGISTRAR AND SAY, "I WANT TO REGISTER MY INFORMATION."
SO THE FIRST THING DO I IS I'M GOING TO GO IN HERE AND I'M GOING TO CREATE HOSTS, HOST RECORDS.
I'M GOING TO CHOOSE TO DO IT THIS WAY.
NS0.CHILD.
AND I'M GOING TO BASICALLY SAY I WANT TO CREATE A HOST RECORD FOR THE FIRST NAME SERVER.
AND I ADD THAT ALSO.
AND WHAT'S HAPPENING IS, IN THIS WINDOW UP HERE, I'M GOING TO PULL THIS ONE UP AND TRY TO MAKE THIS A LITTLE BIGGER.
AND IF -- IT'S PROBABLY VERY HARD TO SEE.
BUT I'VE ADDED THOSE RECORDS TO THE DNS.
SO, BASICALLY, THE REGISTRATION PROCESS HAS ALREADY GONE IN FROM THE REGISTRANT SAYING HERE ARE MY NAME SERVERS IN THIS WINDOW DOWN HERE, AND NOW THEY ARE ALREADY ADDED TO THE REGISTRY.
NORMALLY, I WOULDN'T SEE IT IN THE DNS RIGHT AWAY.
IT WOULD GO INTO THE DATABASE.
BUT BECAUSE I DON'T HAVE A DATABASE, IT'S GOING RIGHT TO THE DNS.
SO NOW THE NEXT STEP IS TO CREATE THE REGISTRATION.
SO I WANT TO UPDATE THE DOMAIN CHILD.TLD IS THE REQUESTED NAME.
AND WHAT I NEED TO HAVE IN HERE IS I NEED TO HAVE NS RECORDS.
AND I ADD THAT.
AND IN A FEW SECONDS, YOU SHOULD SEE A BUNCH OF NS RECORDS ADDED TO THE DNS.
NOW, OF COURSE, WHAT I'M MISSING, REGISTERING NAMES IS NOT THIS EASY.
WHAT'S NOT BEING SHOWN HERE IS CONTACT INFORMATION.
I'M NOT GETTING THE BILLING INFORMATION.
THERE'S A WHOLE LOT MORE BEYOND THIS.
BUT AT LEAST NOW I HAVE THE ABILITY TO SAY, THROUGH THE STANDARD INTERFACE, THIS EPP INTERFACE, THAT, YES, I'M GETTING DATA INTO MY DNS AUTOMATICALLY.
NOW FOR DNSSEC -- THIS IS WHAT WE DO TODAY.
THIS IS NOTHING -- THAT'S NOTHING NEW THERE.
WHAT I HAVE NOW IS, I WANT TO ADD THIS NEW RECORD, THE DS RECORD, WHICH IS GOING TO BE STORED IN A CERTAIN FILE.
AND THE TOOLS CHANGE.
BUT IN THIS CASE, I HAVE IT IN A FILE.
I WANT TO SAY I WANT TO UPDATE MY DOMAIN, CHILD.TLD.
AND I'M GOING TO ADD A DS RECORD.
AT THIS POINT, I WILL DO THE CUT AND PASTE, SINCE IT'S A LITTLE EASIER.
I NEED INFORMATION RIGHT OUT OF THE RECORD AS IT'S GIVEN TO ME BY THE TOOLS.
AND THE MOST INTERESTING THING TO THE DNS ENGINEERS IS THIS BIG LONG THING.
AND THAT -- BASICALLY, I HAVE JUST TAKEN THE INFORMATION RIGHT FROM THE DS RECORD GIVEN TO ME BY THE TOOL, JUST PUTTING IT UP INTO MY CUT AND PASTE INTERFACE, BUT I'M ALSO GOING TO GIVE YOU THIS OTHER NUMBER WHICH IS LIMITING THE LENGTH OF TIME THAT THIS RECORD IS GOING TO BE SIGNED FOR.
USUALLY THAT MIGHT BE ON THE ORDER OF A MONTH, FOR EXAMPLE. SO WHEN I ADD THAT, YOU CAN SEE THINGS IN THE BACKGROUND HERE COMMUNICATED.
WHAT I'M LOOKING FOR NOW IS MY LITTLE UPDATER TO GO THROUGH HERE.
AND IT'S (INAUDIBLE) 15 SECONDS RIGHT NOW.
MATTER OF FACT, IT'S ALREADY HAPPENED.
WHAT I HAVE SEEN NOW IS I ALREADY HAVE A DS RECORD APPEARING IN THE DNS.
NOW, WHAT THAT MEANS IS, IF I LOOK FOR WWW.CHILD.TLD, AT MY LOCAL NAME SERVER, AND I WANT TO SEE THE DNSSEC INFORMATION, WHAT WILL COME BACK, EVERY TIME I ASK FOR THE WEB PAGE THERE, THE REGISTRY IS NOT GOING TO SAY "I DON'T HAVE THE INFORMATION FOR THAT ADDRESS, I DON'T HAVE THE WEB SERVER ADDRESS."
BUT IF YOU GO TO THESE NAME SERVERS, YOU'LL FIND IT.
AND BY THE WAY, THERE'S SECURITY APPLIED TO THE ZONE.
AND THAT'S WHAT WE'RE AFTER AT THE REGISTRIES.
SO I CAN SAY IF YOU PRETEND THAT YOU DON'T HEAR THE NOISE, THIS PROTOTYPE IS WORKING.
NOW, TO CONCLUDE, INFORMATION THAT I'M TALKING ABOUT IS CONTAINED IN A FEW DOCUMENTS.
RFC 4033, 4034, 4035 WE MENTIONED IN VARIOUS PLACES.
THAT'S THE DEFINITION OF DNSSEC.
EPP-DNSSEC IS GIVEN IN ANOTHER DRAFT CALLED DRAFT HOLLENBECK EPP.
THERE WAS A VERSION THAT CAME OUT AT THE END OF LAST WEEK, WHICH IS DASH 07.
THE LINK IS HERE.
THAT SHOULD BE IN THE PRINTOUT, TOO.
SO.... OKAY.
APPARENTLY THIS PRESENTATION IS DONE -- OPEN TO DISCUSSION.
YOU CAN CATCH MY AFTERWARDS.
BUT I BELIEVE WE ARE GOING TO SKIP THE NEXT TWO PRESENTATIONS.
WE'RE SKIPPING THE CERTIFICATE PRESENTATION, AND, I BELIEVE, THE ENUM PRESENTATION.
>> YES.
>>ED LEWIS: AND WE ARE GOING TO GO TO STEVE CROCKER TO GIVE US A WRAP-UP DISCUSSION OF WHAT WE'VE COVERED TODAY.
>>ALLISON MANKIN: WHILE STEVE IS SETTING UP -- THIS ISN'T ON.
OKAY.
I'LL JUST MENTION THAT ANYONE WHO IS INTERESTED IN THE ENUM PRESENTATION, THERE'S COPIES OF IT, BECAUSE IT WAS IN ON TIME.
AND PEOPLE COULD CONTACT THE -- CONTACT US FOR QUESTIONS.
BECAUSE THE COPIES HAVE QUESTION CONTACT INFORMATION.
SO WE'RE SORRY TO DROP THAT.
>>STEVE CROCKER: I NEED A -- SOMEHOW, I NEED TO BE CONNECTED.
SO I GIVE YOU AN EXAMPLE OF REAL-TIME SCHEDULING HERE -- YES?
NO?
HOW WEIRD?
NOW I'M MYSTIFIED.
OH, IS THIS TURNED ON?
THERE WE GO.
SO I WAS MADLY MAKING SLIDES JUST TO TRY TO GET THIS MESSAGE UP.
BUT THE TALKS THAT ARE -- THAT WE'VE HAD ARE AVAILABLE IN HARD COPY AND ALSO ON THE WEB SITE.
THERE WE GO.
WE HAVE A DNSSEC DEPLOYMENT WEB SITE.
THE ADDRESS FOR THE OVERALL WEB SITE IS WWW.DNSSEC-DEPLOYMENT.ORG.
AND WITHIN THAT, THERE WILL BE THE SLIDES FROM THIS WORKSHOP, INCLUDING THE ONES THAT YOU DIDN'T GET TO SEE, SLASH MDP FOR MAR DEL PLATA, WORKSHOP.PHP.
PROBABLY TAKE US UNTIL TOMORROW TO GET IT ALL PUT TOGETHER THERE.
AND HOPEFULLY THERE WILL BE EASY DIRECTION FROM THE TOP LEVEL IF YOU JUST REMEMBER THE NAME OF THE WEB SITE.
I WANT TO DO TWO THINGS AND DO THEM FAIRLY QUICKLY.
AND THEN, AS PROMISED BEFORE, RELEASE EVERYBODY TO MAKE THE MAD SCRAMBLE UPSTAIRS FOR LUNCH AND MOVE THE WHOLE SESSION FORWARD.
FIRST OF ALL, I WANT TO THANK EVERYBODY FOR COMING, AND PARTICULARLY FOR SITTING THROUGH A LENGTHY SESSION.
AND I WANT TO EQUALLY THANK THE -- QUITE A LARGE NUMBER OF PEOPLE WHO PUT A LOT OF TIME INTO PREPARING TALKS AND COORDINATING WITH EACH OTHER TO BRING ALL OF THIS TO YOU.
THERE'S QUITE A LOT OF WORK, AS YOU KNOW.
AND THE OTHER THING IS, THIS IS A GOOD TIME TO GET A LITTLE BIT OF RESPONSE BACK FROM YOU WHO HAVE ATTENDED.
AND THE KEY QUESTION IS, HOW USEFUL HAS THIS BEEN FOR YOU? WHAT WOULD YOU HAVE LIKED TO HAVE SEEN?
WHAT CHANGES CAN WE MAKE OVER TIME?
WE ARE GOING TO BE ENGAGED IN A REPETITIVE SERIES OF WORKSHOPS OVER TIME, IN PARTICULAR, WE HAVE TENTATIVE PLAN AT THE LUXEMBOURG ICANN MEETING TO HAVE A VERSION OF THIS KIND OF WORKSHOP THAT IS VERY HEAVILY FOCUSED ON REGISTRIES.
AND THEN AT THE VANCOUVER MEETING AT THE END OF THE YEAR, TO HAVE ONE THAT IS FOCUSED ON REGISTRARS.
SO -- AND THERE WILL BE A LOT OF OTHER KINDS OF ACTIVITIES.
BUT THOSE ARE THE ONES THAT WE ARE TARGETING THIS YEAR AROUND ICANN.
SO WITH THAT, LET ME OPEN THE FLOOR AND ASK FOR FEEDBACK, EVALUATION.
YOU'RE WELCOME TO SAY POSITIVE THINGS, TOO.
BUT THE MORE USEFUL THINGS ARE THE CONSTRUCTIVE CRITICISM, IF YOU WILL.
SURELY SOMEBODY IS ITCHING TO SAY SOMETHING?
NO?
I HAVE NEVER SEEN SUCH A LARGE CONSENSUS FOR LUNCH IN MY LIFE.
WELL, OKAY.
FEEL -- DO FEEL FREE TO GIVE FEEDBACK INFORMALLY, PRIVATELY, ELECTRONICALLY, HOWEVER YOU WISH.
AND, AGAIN, THANK YOU VERY MUCH FOR COMING.
I HOPE THIS WAS USEFUL TO YOU AND HOPE THAT IT SERVES THE PURPOSE OF ADVANCING THE DEPLOYMENT PROCESS FOR DNSSEC, AND LOOK FORWARD TO SEEING ALL OF YOU IN RELATED FORUMS OVER A PERIOD OF TIME.
SO WITH THAT, YOU GET A VERY FINE HEAD START ON LUNCH, AND I THINK THAT'LL BE APPRECIATED.
THANK YOU.
(APPLAUSE.)