Internet2 DNSSEC Pilot Shumon Huque University of Pennsylvania Sprint Internet2 Member Meeting Arlington, Virginia, U.S.A., Apr 23rd 2007

Shumon Huque2 This is mostly a repeat of a presentation I gave at the Winter 2007 Joint Techs meeting, February 2007, Minneapolis, Minnesota, U.S.A.

Shumon Huque3 Description of the Pilot Deploy DNSSEC Gain Operational experience Does it work (does it catch anything?) Test DNSSEC aware applications Participants sign at least one of their zones Exchange keys (trust anchors) that will allow them to mutually validate DNS data

Shumon Huque4 What is DNSSEC? A system to verify the authenticity of DNS “data” RFC 4033, 4034, 4035 Helps detect: spoofing, misdirection, cache poisoning Some secondary benefits appear: You could store keying material in DNS DKIM, SSHFP, IPSECKEY, etc

Shumon Huque5 A little background.. Feb ‘06: DNSSEC Workshop held at Albuquerque Joint Techs Mar ‘06: mailing list Apr ‘06: Internet2 Spring Member meeting Advisory group formed and plans for a pilot project formulated May ‘06: Pilot group began Monthly conference calls and progress reports

Shumon Huque6 Co-ordination Internet2 Shinkuro シンクロ Partner in DNSSEC Deployment Initiative Some funding from US government

Shumon Huque7 DNSSEC Deployment Efforts so far MAGPI GigaPoP All zones: magpi.{net,org} & 15 reverse zones MERIT radb.net nanog.org NYSERNet - test zone nyserlab.org

Shumon Huque8 Others considering or planning deployment University of Pennsylvania University of California - Berkeley University of California - Los Angeles University of Massachusetts - Amherst Internet2

Shumon Huque9 DLV (DNSSEC Lookaside Validation) A mechanism to securely locate DNSSEC trust anchors “off-path” An early deployment aid until top-down deployment of DNSSEC happens Pilot group is in talks to make use of ISC’s DLV registry More on this at a later date..

Shumon Huque10 More participants welcome! (participation not restricted to Internet2) Join mailing list Participate in conference calls

Shumon Huque11 Thoughts on deployment obstacles (1) A Chicken & Egg problem Marginal benefits, until much more deployment Why should I go first? We had (have?) the same problem with other technologies (IPv6 etc) Some folks will need to take the lead, if there is hope for wider adoption Good way to find out how well it works

Shumon Huque12 Thoughts on deployment obstacles (2) Operational stability More complicated software infrastructure New processes for: Zone changes Secure delegations Security (protection of crypto keys) Key rollover and maintenance Integration w/ existing DNS management software What is the experience of the pilot?

Shumon Huque13 Thoughts on deployment obstacles (3) Additional system requirements Authoritative servers: memory Resolvers: memory & CPU Memory use can be calculated Probably not a big issue (unless you’re.COM!) CPU Not too much of an issue today (dearth of signed data that needs validation) Caveat: some potential DoS attacks could hit CPU

Shumon Huque14 Thoughts on deployment obstacles (4) Key distribution in islands of trust Why is there no top down deployment? Work on signing root and (many) TLDs and in- addr.arpa is in progress.SE, RIPE reverse done.EDU work in motion Interim mechanisms like DLV exist Manual key exchange (unscalable)

Shumon Huque15 Thoughts on deployment obstacles (5) Stub resolver security (e2e security) An area of neglect in my opinion Push DNSSEC validation to endstations? Secure path from stub resolver to recursive resolver Possibilities: SIG(0), TSIG, IPSEC

Shumon Huque16 Thoughts on deployment obstacles (6) Application layer feedback Coming gradually DNSSEC aware resolution APIs and applications enhanced to use them DNSSEC aware applications See Note: some folks think it might be nice to protect DNSSEC oblivious applications silently as an interim step

Shumon Huque17 Thoughts on deployment obstacles (7) Zone enumeration threat See NSEC3 record (spec almost done) draft-ietf-dnsext-nsec3-09.txt Hashed Authenticated Denial of Existence Also provides “Opt-Out” (to allow spans of unsecured records in a signed zone)

Shumon Huque18 Additional BoF topics

Shumon Huque19 DLV participation procedures See Joao Damas’ earlier presentation ISC DLV registry Policy and practice statement:

Shumon Huque20 edu Top-Level-Domain signing Who’s involved: Educause, Verisign, US Dept of Commerce What can Internet2 schools do to help make this a reality? NSEC3 is not needed: edu zone is small (< 8000 delegations) Relatively static No zone privacy requirements

Shumon Huque21 Securing last hop(s) Most university threat models include untrustworthiness of the local network ie. path between client and recursive resolver is NOT secure Need stub resolvers capable of: 1. Validating DNSSEC signatures, or 2. Supporting channel protection mechanisms that allow them to authenticate response from recursive resolver SIG(0), TSIG etc

Shumon Huque22 Securing last hop(s) cont.. Which channel protection mechanism? Simple symmetric key TSIG has problems Can’t distribute same TSIG key to many clients - that allows any of them to forge DNS answers to others Need per-client keys and thus additional key management infrastructure SIG(0) may be more manageable A public key signature of the response msg Need to only distribute the public key

Shumon Huque23 Application feedback DNSSEC aware resolution API/libraries eg. draft-hayatnagarkar-dnsext-validator-api-03 Plus applications enhanced to use them

Shumon Huque24 References Internet2 DNSSEC Pilot Mailing list: Internet2 DNSSEC Workshop albuquerque/sessionDetails.cfm?session=2491&ev ent=243

Shumon Huque25 References (2) DNSSEC(bis) technical specs: RFC 4033, 4034, 4035 Related: DNSSEC HOWTO: Threat analysis of the DNS: RFC 3833 Operational practices: RFC 4641 NSEC3: draft-ietf-dnsext-nsec3-09 DLV: draft-weiler-dnssec-dlv-01 draft-hubert-dns-anti-spoofing-00

Shumon Huque26 Questions? Shumon Huque shuque -at- isc.upenn.edu