dnssec deployment - internet society · dnssec evangelist of the day ¥nlnet labs Ðnot for profit...
TRANSCRIPT
CC-TLD Workshop, Sofia© 24 October 2006 Stichting NLnet Labs
http://www.nlnetlabs.nl/
DNSSEC Deployment
Olaf M. [email protected]
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 2
NLnetLabs
DNSSEC evangelist ofthe day
• NLnet Labs– Not for profit Open Source Software lab
• Developed NSD
– DNS and DNSSEC research• Protocol and software development
• Deployment engineering
• Active IETF participant– co-chair of the IETF DNSEXT working group
– member of the Internet Architecture Board
– RFC3757 and RFC4061
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 3
NLnetLabs
Outline
• purpose and protocol
• Current Developments/problem areas
• Deployment, system architecture
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 4
NLnetLabs
Why DNSSEC
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 5
NLnetLabs
Bourtange, source Wikipedia
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 6
NLnetLabs
Why DNSSEC
• Defense layers– Multiple defense rings in physical secured
systems
– Multiple ‘layers’ in the networking world
• DNS infrastructure– Providing DNSSEC to raise the barrier for
DNS based attacks
– Provides a security ‘ring’ around many systemsand applications
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 7
NLnetLabs
The Problem• DNS data published by the registry is being replaced on its
path between the “server” and the “client”.
• This can happen in multiple places in the DNSarchitecture
– Some places are more vulnerable to attacks then others
– Vulnerabilities in DNS software make attacks easier(and there will always be software vulnerabilities)
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 8
NLnetLabs
ISP
DNS service
DNS Provider
DNS Architecture
Registry DB
primary
secondary
Cache server
Registrars/
Registrants
client
DNS ProtocolProvisioning
secondary
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 9
NLnetLabs
DNS Architecture
Registry DB
Server compromise
Registrars
Registrants
DNS ProtocolProvisioning
Inter-server
communicationCache Poisoning
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 10
NLnetLabs
Astrophysics
Mail ServerAstrophysics
Mail Server
Example:Unauthorized mail
scanning
DNSDNS
Central Admin
Mail ServerCentral Admin
Mail Server
Where?
There!
Subject: tenure
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 11
NLnetLabs
Astrophysics
Mail ServerAstrophysics
Mail Server
Example:Unauthorized mail
scanning
DNSDNS
Central Admin
Mail ServerCentral Admin
Mail Server
Where?Elsewhere
Bad GuyBad Guy
Subject: tenure
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 12
NLnetLabs
Targets; Where do DNS andeconomics meet?
• SPF, DomainKey and family
– Technologies that use the DNS to mitigate spam and phishing:$$$ value for the black hats
• Stock tickers, RSS feeds
– Usually no source authentication but supplying false stockinformation via a stock ticker and via a news feed can have $$$value
• ENUM
– Mapping telephone numbers to services in the DNS
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 13
NLnetLabs
Where Does DNSSECCome In?
• DNSSEC secures the name to addressmapping
– Tranport and Application security are justother layers.
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 14
NLnetLabs
Solutiona Metaphor
• Compare DNSSEC to a sealed transparentenvelope.
• The seal is applied by whoever closes theenvelope
• Anybody can read the message
• The seal is applied to the envelope, not tothe message
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 15
NLnetLabs
DNSSEC protection
Registry DB
Registrars
Registrants
DNS ProtocolProvisioning
‘envelope sealed’ ‘Seal checked’
‘Seal checked’
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 16
NLnetLabs
DNSSEC hypersummary
• Data authenticity and integrity by signingthe Resource Records Sets with private key
• Public DNSKEYs used to verify the RRSIGs
• Children sign their zones with their privatekey– Authenticity of that key established by
signature/checksum by the parent (DS)
• Ideal case: one public DNSKEY distributed
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 17
NLnetLabs
New Resource Records
• Three Public key crypto related RRs
– RRSIG Signature over RRset made usingprivate key
– DNSKEY Public key, needed for verifying aRRSIG
– DS Delegation Signer; ‘Pointer’ for building chains of authentication
• One RR for internal consistency
– NSEC authenticated non-existence of data
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 18
NLnetLabs
DNSSEC secondarybenefits
• DNSSEC provides an “independent” trustpath– The person administering “https” is most
probably a different from person from the onethat does “DNSSEC”
– The chains of trust are most probably different
– See acmqueue.org article: “Is HierarchicalPublic-Key Certification the Next Target forHackers?”
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 19
NLnetLabs
More benefits?
• With reasonable confidence performopportunistic key exchanges
– SSHFP and IPSECKEY Resource Records
• With DNSSEC one could use the DNS fora priori negotiation of securityrequirements.
– “You can only access this service over a securechannel”
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 20
NLnetLabs
DNSSEC properties
• DNSSEC provides message authentication andintegrity verification through cryptographicsignatures
– Authentic DNS source
– No modifications between signing and validation
• It does not provide authorization
• It does not provide confidentiality
• It does not provide protection against DDOS
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 21
NLnetLabs
DDOS and the DNS
• Reflector attacks– Recently Open recursive servers used to amplify traffic
– several Gbits/second traffic to critical infrastructure
– Source addresses at DDOS target are valid, packetformat valid
• an UDP problem
• DNS has nice amplification characteristics
• ‘closing open resolvers’ helps, but authoritativeservers will do to
• You make the packets smaller? We’ll just wake upmore zombies
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 22
NLnetLabs
Remedy: Ingressfiltering (BCP38)
Zombie botnet
Drop packets ifsource address is‘strange’ to thenetwork
http://www.ietf.org/rfc/rfc2827.txt(BCP38)
“Network Ingress Filtering:Defeating Denial of Service Attacks whichemploy IP Source Address Spoofing”
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 23
NLnetLabs
Outline
• purpose and protocol
• Current Developments/problem areas
• Deployment, system architecture
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 24
NLnetLabs
Main Problem Areas
• “the last mile”
• Key management and key distribution
• NSEC walk
improvement
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 25
NLnetLabs
The last mile
` APP
STUB
• How to get validation results back tothe user
• The user may want to make differentdecisions based on the validationresult
– Not secured
– Time out
– Crypto failure
– Query failure
• From the recursive resolver to thestub resolver to the Application
validating
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 26
NLnetLabs
Last MileCurrent Work
• A lot of vapor and brain ware
• Only one java-based prototype for secureresolving
– Used for studying API issues
– NLnet Labs started work on a port to C
• Cooperation with Nominet and Verisign
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 27
NLnetLabs
Problem Area
` APP
STUB
Key Management
• Keys need to propagate fromthe signer to the validatingentity
• The validating entity willneed to “trust” the key to“trust” the signature.
• Possibly many islands ofsecurity
signing
validating
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 28
NLnetLabs
Secure Islands and keymanagement
net.
money.net.kids.net.
geerthecorp
dev market dilbert
unixmacmarnick
nt
os.net.
com.
.
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 29
NLnetLabs
Secure Islands
• Server Side– Different key management policies for all these islands
– Different rollover mechanisms and frequencies
• Client Side(Clients with a few to 10, 100 or more trust-anchors)
– How to keep the configured trust anchors in sync withthe rollover
– Bootstrapping the trust relation
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 30
NLnetLabs
Key ManagementCurrent Work
• Rolling configured keys automatically
– Final stages of DNSEXT WG.
• Last call on draft-ietf-dnsext-trustupdate-timers andan accompanying requirement document
• Key distribution mechanisms have beenproposed
– None get very much traction
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 31
NLnetLabs
Key ManagementCurrent Work
• BIND 9.4 includes DLV• When a zone turns out to be signed and the key is
not available the validator looks in a dedicated partof the namespace maintained by the DLV registry
• Not designed to last, not brought to the IETF bythe implementors
– draft-weiler-dnssec-dlv
– Last call IETF, informational
– Follows implementation(?)
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 32
NLnetLabs
DLVsecure entry points stored in dlv.isc.org
net.
money.net.kids.net.
geerthecorp
dev market dilbert
unixmacmarnick
nt
os.net.
com.
.
dlv.isc.org
org.
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 33
NLnetLabs
NSEC walk
• The record for proving the non-existence of dataallows for zone enumeration
• Providing privacy was not a requirement forDNSSEC
• Zone enumeration does provide a deploymentbarrier
• Work starting to study possible solutions– will be co-existing with DNSSEC-BIS !!!
– Until then on-line keys will do the trick.
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 34
NLnetLabs
NSEC walkCurrent Work
• Online creation and signing of NSEC RRsthat cover the query name– RFC4470 and RFC4471
• NSEC3– Hashed based denial of existence
– draft-ietf-dnsext-
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 35
NLnetLabs
NSEC3 Features
• Interaction with DNS wildcards– Multiple proofs of non-existence needed
• OPT-out bit added– Changes security model of DNSSEC somewhat
• Delegations ranges can be opted out: delegationswithin that range are not proven not to exist.
– Needed for deployment in .com• 40 Million NSEC/NSEC3 RRs with signature
information is painful
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 36
NLnetLabs
NEC3 featurescontinued
• Dictionary attack resilient:
– Through use of salt
– Through use of itterations
• Also higher costs to servers and resolvers
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 37
NLnetLabs
Outline
• purpose and protocol
• Current Developments/problem areas
• Deployment, system architecture
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 38
NLnetLabs
Common argumentsagainst
• DNSSEC is to complex to deploy– The weapon with which to shoot oneself in the foot is
not a pop-gun but a military grade full automatic
• The root will never get signed
• There is no economy to push deployment
• Cache poisoning can be mitigated by correctlyimplementing random query ports and properquery ID
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 39
NLnetLabs
What’s keeping folk
• New technology; chicken and egg
• Zone walking possibility
– Is this really an issue in your environment?
– Solutions are being engineered
• Automated key rollover and distribution
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 40
NLnetLabs
Early players
• Demonstrate the ability to self-regulate
– Before the guys up the hill (or from Brussels)force it down your throat
– Before a bad thing happens and you are wokenup at 2 am
• Lead by example
– Break the egg
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 41
NLnetLabs
The role of DNSRegistries
• Good Netizens
– Being Involved, recognizing the problem
– Community education and awareness raising
• Registration Services
– Under appropriate circumstances providingregistration data to appropriate authorities
• DNS infrastructure
– Providing DNSSEC to raise the barrier for DNS basedattacks
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 42
NLnetLabs
DNSSEC deploymentpracticalities
• RIPE NCC deployed DNSSEC on thereverse tree
– Followed the architecture to plan the changesto the system
• You may want to follow the same stepswhen planning for local DNSSECdeployment
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 43
NLnetLabs
DNSSECArchitecturemodifications
Primary DNS
Secondary
DNS
Customer
interfaces
Zone signer
DNSSEC
aware servers
DNS and input
checks
Provisioning
DB
Zone
Creation
DNSSEC aware provisioning
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 44
NLnetLabs
Server Infrastructure
• Part of keeping up to date
– Your most recent version of BIND and NSDrun DNSSEC
• Memory might be an issue
– Predictable (see RIPE352)
• Coordination with secondaries
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 45
NLnetLabs
Provisioning
• Realize that interaction with child is notdrastically different.
– DS and NS have the same security properties
– You may need to respond a bit different to‘child’ emergency cases
• Thinking “security” will make you notice“security”
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 46
NLnetLabs
Key Mastering andSigning
• Key management and signing needs to bereliable
– Failure will lead to loss of service
• Cost factors:
– Automation and Education
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 47
NLnetLabs
Instruct your lawyers
• A DNSSEC signature is not a certification for thecorrectness of the provisioned data
• It only serves to proof that the data is not changed after itmade its transition from the provisioning system into theDNS
• DNSSEC validation failures indicate possible maliciousactivity
• Do not put legal weight on DNSSEC signatures
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 48
NLnetLabs
Concluding remarks
• DNSSEC is not a magic bullet but may become animportant component
– By providing the infrastructure apps and resolver developmentshould follow
• U.S. Federal requirement
– Federal agencies will need to support DNSSEC
– http://www.dnssec-deployment.org/news/FISMA.htm
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 49
NLnetLabs
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 50
NLnetLabs
QUESTIONS?
Acknowledgements: A number of these slides are based on earlier work at RIPE NCC.
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 51
NLnetLabs
References I
Without claims to completeness…
RFCs can be found at http://www.ietf.org/rfc/
Internet drafts are at http://www.ietf.org/internet-drafts/
• DNSSEC bis:– RFC4033,4034,4035
• Authenticated denial:– Online signing:
• RFC4470, RFC4471
– NSEC3: draft-ietf-dnsext-dnssec-nsec3
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 52
NLnetLabs
Rerferences II Key Anchor maintenance
• DLV: IEICE Trans. Commun. Vol. E88-B,No. 4, April 2005
• Trustupdate proposals
– draft-ietf-dnsext-trustupdate-threshold
– draft-ietf-dnesxt-trustupdate-timers
– draft-moreau-dnsext-takrem-dns
– draft-laurie-dnssec-key-distribution
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 53
NLnetLabs
References III Operational
• RFC4641
• RIPE 352– http://www.ripe.net/ripe/docs/ripe-352.html
• DNSSEC HOWTO– http://www.ripe.net/disi/dnssec_howto/
• draft-hayatnagarkar-dnsext-validator-api
• Geoff Hustons experiences– ispcolumn.isoc.org or www.potaroo.net
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 54
NLnetLabs
References IVWebsites
• www.dnssec-deployment.org
• www.dnssec.net
• RIPE DNSSEC deployment (howto, keymanagement toolsetc)– www.ripe.net/disi/
• DNSSEC testbed and testing tools developed by NIST– http://www-x.antd.nist.gov/dnssec/
• DNSSEC tools available at– http://www.dnssec-tools.org/
CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/
page 55
NLnetLabs
References VDeployment Initiatives
• http://dnssec.nic.se/
• http://www.dnssec.ru/
• https://www.ripe.net/rs/reverse/dnssec/