1 / 18

State of DNS Security Extensions

State of DNS Security Extensions. Edward Lewis February 26, 2001 APRICOT 2001 Panel. Agenda. Brief overview of DNS Security Extensions Current state of specifications Current state of software Efforts underway. DNSSEC Components. Name server to name server protections

roanna-barnett
Download Presentation

State of DNS Security Extensions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. State of DNS Security Extensions Edward Lewis February 26, 2001 APRICOT 2001 Panel

  2. Agenda • Brief overview of DNS Security Extensions • Current state of specifications • Current state of software • Efforts underway

  3. DNSSEC Components • Name server to name server protections • Digital signatures, KEY, SIG, NXT records • Scaleable, Internet-wide transfers • Query/Response protections • TSIG addition to message, also a digital sig approach • Resolver to "default" name server, zone transfer • Publication of certificates • Distribution of X.509, PGP certificates, CERT record • Dynamic update security • Authentication and authorization to change zones

  4. DNSSEC in the network top level domain root server authoritative name server KEY RR, SIG RR, NXT RR conference machine TSIG recursive (conference net) name server

  5. IETF Status • The current document set is at the Proposed Standard level • Documents are listed in upcoming slides • The documents are to be rewritten as early experience is gained • The goal is to progress to Draft Standard in 2002

  6. Implementations • ISC's BIND • First in version 8.2 • Full implementations starting in version 9 • Current version 9.1.x • Some implementations in other code bases, none are publicly or widely available

  7. KEY, SIG and NXT • Documents • RFC 2535, Basic definition • RFC 2536, 2537 Key and signature algorithms • RFC 2539 Diffie-Hellman keys • Updates to this set • RFC 3008 Signing authorization model • More coming soon

  8. What works • Key generation • Making, storing keys • Signing and loading zones • Addition of signatures, NXTs, to zones • Basic validation of data • Resolver fetches keys and verifies signatures

  9. Remaining Issues • Validation of child by parent (delegator) • Child zone keys have to signed by parent zone • Impact on high-volume TLDs • Negative response issues • NXT record does not satisfy everyone • Impact on staff operations • Management and protection of keys • Need to sign zone data at intervals • regular intervals - week? month? year? • Interaction with parent zone

  10. Query/Response • Documents • RFC 2535, in the basic definition • Updates • RFC 2845 Secret Key Transaction (TSIG) • RFC 2931 Public Key Query/Response approach

  11. What works • Use of TSIG for zone transfers • Addition of TSIG to authoritative servers to protect NOTIFY and AXFR • Use of TSIG to authorize dynamic updates • Updates can be restricted based upon the key used to sign request

  12. Remaining Issues • Distributing and Configuring Secrets for general queries • General purpose queries, larger scale • Where is the secret stored on a multiuser machine? • Use of TKEY and SIG(0) • Not in widespread use, not much experience

  13. Publishing Certificates • Documents • RFC 2538 Basic definition • What works • CERT Record, simple addition to DNS • Issues • Software for applications to insert and extract certificates from DNS

  14. Securing Dynamic Update • Documents • RFC 2136 Dynamic Update • RFC 2137 Secure Dynamic Update (not implemented) • RFC 3007 Secure Dynamic Update (implemented)

  15. What Works/Issues • Authorizing updates based upon keys used to sign request • No longer need to trust based upon IP address • Keeping signatures up to date • Data not updated becomes stale • Need tools to fix this

  16. Other issues • Need for applications to make use of these new features • E.g., a secure shell implementation that uses keys from DNS • E.g., a web browser that lets user know if the web site's address was digitally signed for protection • E.g., a simple method for users to publish their personal certificates for email

  17. Who's Working On It • Status meeting summarized in • draft-lewis-state-of-dnssec-00.txt • Minutes of December meeting at San Diego IETF • Attendees • NLnet Labs, Verisign, The Foundation for Internet Infrastructure, Root Server System Advisory Committee, National Institute of Standards and Technology, Defense Information Systems Agency, RIPE NCC, Network Associates, Information Sciences Institute

  18. Summary • DNSSEC is a lot of work to define and implement • Progress is happening, but not at a lightening-fast rate • There is a lot of interest in the technology • No matter the outcome, maintaining security will always increase workload, • We do want to keep the increase to a minimum

More Related