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

2. Slide 2 P R O T E C T I N G Y O U R P R I V A C Y 2lewis@tislabs.com APRICOT 2001 Agenda  Brief overview of DNS Security Extensions  Current state of specifications  Current state of software  Efforts underway

3. Slide 3 P R O T E C T I N G Y O U R P R I V A C Y 3lewis@tislabs.com APRICOT 2001 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. Slide 4 P R O T E C T I N G Y O U R P R I V A C Y 4lewis@tislabs.com APRICOT 2001 DNSSEC in the network root server top level domain authoritative name server recursive (conference net) name server KEY RR, SIG RR, NXT RR conference machine TSIG

5. Slide 5 P R O T E C T I N G Y O U R P R I V A C Y 5lewis@tislabs.com APRICOT 2001 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. Slide 6 P R O T E C T I N G Y O U R P R I V A C Y 6lewis@tislabs.com APRICOT 2001 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. Slide 7 P R O T E C T I N G Y O U R P R I V A C Y 7lewis@tislabs.com APRICOT 2001 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. Slide 8 P R O T E C T I N G Y O U R P R I V A C Y 8lewis@tislabs.com APRICOT 2001 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. Slide 9 P R O T E C T I N G Y O U R P R I V A C Y 9lewis@tislabs.com APRICOT 2001 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. Slide 10 P R O T E C T I N G Y O U R P R I V A C Y 10lewis@tislabs.com APRICOT 2001 Query/Response  Documents  RFC 2535, in the basic definition  Updates  RFC 2845 Secret Key Transaction (TSIG)  RFC 2931 Public Key Query/Response approach

11. Slide 11 P R O T E C T I N G Y O U R P R I V A C Y 11lewis@tislabs.com APRICOT 2001 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. Slide 12 P R O T E C T I N G Y O U R P R I V A C Y 12lewis@tislabs.com APRICOT 2001 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. Slide 13 P R O T E C T I N G Y O U R P R I V A C Y 13lewis@tislabs.com APRICOT 2001 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. Slide 14 P R O T E C T I N G Y O U R P R I V A C Y 14lewis@tislabs.com APRICOT 2001 Securing Dynamic Update  Documents  RFC 2136 Dynamic Update  RFC 2137 Secure Dynamic Update (not implemented)  RFC 3007 Secure Dynamic Update (implemented)

15. Slide 15 P R O T E C T I N G Y O U R P R I V A C Y 15lewis@tislabs.com APRICOT 2001 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. Slide 16 P R O T E C T I N G Y O U R P R I V A C Y 16lewis@tislabs.com APRICOT 2001 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. Slide 17 P R O T E C T I N G Y O U R P R I V A C Y 17lewis@tislabs.com APRICOT 2001 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. Slide 18 P R O T E C T I N G Y O U R P R I V A C Y 18lewis@tislabs.com APRICOT 2001 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