introducing dnssec › ... › courses › cia › uva-dnssec-06.pdfdnssec evangineers of olaf: the...

1

Universiteit van Amsterdam, Sep 2006© 21 September 2006 Stichting NLnet Labshttp://www.nlnetlabs.nl/

An introduction toDNSSECOlaf KolkmanNLnet Labs

Universiteit van Amsterdam, Sep 2006http://www.nlnetlabs.nl/

page 2

NLnetLabs

Rough Outline

• Introduction• Why DNSSEC• DNSSEC Theory• Famous last words


page 3

NLnetLabs

DNSSEC evangineers ofthe dayOlaf:

• NLnet Labs (www.nlnetlabs.nl)– DNS and DNSSEC research

• Protocol and software development (NSD)

• Co-Chair of the IETF DNSEXT working group• Member of the Internet Architecture Board• DNSSEC experience since about 2001

– DNSSEC deployment at RIPE NCC– DNSSEC Howto– Net::DNS::SEC extensions– RFC 4641 on DNSSEC operations


page 4

NLnetLabs

The Material

• Based on material developed while I waswith the RIPE NCC. They areacknowledged for allowing me to re-usethis material


IntroducingDNSSEC


page 6

NLnetLabs

Why DNSSEC

• Good security is multi-layered– Multiple defense rings in physical secured

systems


page 7

NLnetLabs

Bourtange, source WikipediaUniversiteit van Amsterdam, Sep 2006http://www.nlnetlabs.nl/

page 8

NLnetLabs

Why DNSSEC

• Good security is multi-layered– 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 systems

and applications


page 9

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 DNS

architecture– Some places are more vulnerable to attacks then others

– Vulnerabilities in DNS software make attacks easier(and there will always be software vulnerabilities)

2


page 10

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 to

the message


page 11

NLnetLabs

edu institution as ISP

edu as ‘friend’

edu as DNS provider

DNS Architecture

Registry DB

primary

secondary

Cache server

Registrars/Registrants

client

DNS ProtocolProvisioningsecondary


page 12

NLnetLabs

DNS Architecture

Registry DB

Server compromise

RegistrarsRegistrants

DNS ProtocolProvisioning

Inter-servercommunication

Cache Poisoning


page 13

NLnetLabs

AstrophysicsMail Server


Example:Unauthorized mail

scanning

DNSDNS

Central AdminMail Server


Where?

There!

Subject: tenure


page 14

NLnetLabs



Example:Unauthorized mail

scanning

DNSDNS



Where?Elsewhere

Bad GuyBad Guy

Subject: tenure


page 15

NLnetLabs

Where Does DNSSECCome In?

• DNSSEC secures the name to addressmapping– Tranport and Application security are just

other layers.


page 16

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 Hierarchical

Public-Key Certification the Next Target forHackers?”


page 17

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 secure

channel”


page 18

NLnetLabs

DNSSEC properties

• DNSSEC provides message authenticationand integrity verification throughcryptographic signatures– Authentic DNS source– No modifications between signing and

validation

• It does not provide authorization• It does not provide confidentiality

3


page 19

NLnetLabs

Other DNS security

• We talked about data protection– The sealed envelope technology– RRSIG, DNSKEY, NSEC and DS RRs

• There is also a transport security component– Useful for bilateral communication between machines– TSIG or SIG0


Questions?

Summary

• DNSSEC is essential for good layeredsecurity

• DNS protocol intrinsically easy to attack

• DNSSEC and Transport security


Securing Host-Host

Communication


page 22

NLnetLabs

TSIG Protection

Registry DB


DNS ProtocolProvisioning dynamic updates

AXFR and IXFR

Queries to cachingforwarers


page 23

NLnetLabs

Transaction Signature:TSIG

• TSIG (RFC 2845)– Authorising dynamic updates and zone transfers– Authentication of caching forwarders– Independent from other features of DNSSEC

• One-way hash function– DNS question or answer and timestamp

• Traffic signed with “shared secret” key• Used in configuration, NOT in zone file


page 24

NLnetLabs

SOA …SOASig ...

Master

AXFR

TSIG Example

SlaveKEY:

%sgs!f23fv

KEY:%sgs!f23f

AXFR

Sig ...Sig ...

SOA …SOASig ...

SlaveKEY:

%sgs!f23f

verification

verification

Query: AXFR

Response: Zone


page 25

NLnetLabs

TSIG for Zone Transfers

1. Generate secret

2. Communicate secret

3. Configure servers

4. Test


page 26

NLnetLabs

Importance of theTime Stamp

• TSIG/SIG(0) signs a complete DNS request/ response with time stamp– To prevent replay attacks– Currently hardcoded at five minutes

• Operational problems when comparingtimes– Make sure your local time zone is properly

defined– date -u will give UTC time, easy to compare

between the two systems– Use NTP synchronisation!


page 27

NLnetLabs

Authenticating ServersUsing SIG(0)

• Alternatively, it is possible to use SIG(0)

– Not yet widely used

– Works well in dynamic update environment

• Public key algorithm

– Authentication against a public key published in the

DNS

• SIG(0) specified in RFC 2931

4


page 28

NLnetLabs

Cool Application

• Use TSIG-ed dynamic updates to configureconfigure your laptops name

• My laptop is know by the name ofgrover.secret-wg.org– http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

– Mac OS users: there is a bonjour based tool.• www.dns-sd.org


Questions?

Summary

• TSIG/Sig(0)• Generate secret

• Configure servers


DNSSECMechanisms

• New Resource Records• Setting Up a Secure Zone• Delegating Signing Authority• Key Rollovers


page 31

NLnetLabs

DNSSEC protection

Registry DB


DNS ProtocolProvisioning

‘envelope sealed’ ‘Seal checked’

‘Seal checked’Universiteit van Amsterdam, Sep 2006http://www.nlnetlabs.nl/

page 32

NLnetLabs

DNSSEC hypersummary

• Data authenticity and integrity by signing theResource Records Sets with private key

• Public DNSKEYs used to verify the RRSIGs• Children sign their zones with their private key

– Authenticity of that key established bysignature/checksum by the parent (DS)

• Ideal case: one public DNSKEY distributed


page 33

NLnetLabs

The DNS is Not a PKI

• All key procedures are based on local policy

• A PKI is as strong as its weakest link– Certificate Authorities control this through SLAs

• The DNS does not have Certificate RevocationLists

• If the domain is under one administrative controlyou might be able to enforce policy


page 34

NLnetLabs

Public Key Crypto

• Key pair: a private (secret) key and acorresponding public key

• Simplified:– If you know the public key, you can verify a signature

created with the private key– If you know the public key, you can encrypt data that

can only be decrypted with the private key

• DNSSEC only uses signatures– PGP uses both methods


page 35

NLnetLabs

Security Status of Data(RFC4035)

• Secure– Resolver is able to build a chain of signed DNSKEY and DS RRs from

a trusted security anchor to the RRset

• Insecure– Resolver knows that it has no chain of signed DNSKEY and DS RRs

from any trusted starting point to the RRset

• Bogus– Resolver believes that it ought to be able to establish a chain of trust

but for which it is unable to do so– May indicate an attack but may also indicate a configuration error or

some form of data corruption

• Indeterminate– Resolver is not able to determine whether the RRset should be

signed


New ResourceRecords

5


page 37

NLnetLabs

RRs and RRSets

• Resource Record:– name TTL class type rdata

www.ripe.net. 7200 IN A 192.168.10.3

• RRset: RRs with same name, class and type:www.ripe.net. 7200 IN A 192.168.10.3

A 10.0.0.3A 172.25.215.2

• RRSets are signed, not the individual RRs


page 38

NLnetLabs

New Resource Records

• Three Public key crypto related RRs– RRSIG Signature over RRset made using private key

– DNSKEY Public key, needed for verifying a RRSIG

– DS Delegation Signer; ‘Pointer’ for building chainsof authentication

• One RR for internal consistency– NSEC Indicates which name is the next one in the

– zone and which typecodes are available for thecurrent name

• authenticated non-existence of data


page 39

NLnetLabs

DNSKEY RDATA– 16 bits: FLAGS– 8 bits: protocol– 8 bits: algorithm– N*32 bits: public key

Example:ripe.net. 3600 IN DNSKEY 256 3 5 (

AQOvhvXXU61Pr8sCwELcqqq1g4JJCALG4C9EtraBKVd +vGIF/unwigfLOAO3nHp/cgGrG6gJYe8OWKYNgq3kDChN)


page 40

NLnetLabs

RRSIG RDATA• 16 bits - type covered• 8 bits - algorithm• 8 bits - nr. labels covered• 32 bits - original TTL

• 32 bit - signature expiration• 32 bit - signature inception• 16 bit - key tag• signer’s name

signature field

ripe.net. 3600 IN RRSIG A 5 2 3600 (20050611144523 20050511144523 3112 ripe.net.

VJ+8ijXvbrTLeoAiEk/qMrdudRnYZM1VlqhN vhYuAcYKe2X/jqYfMfjfSUrmhPo+0/GOZjW 66DJubZPmNSYXw== )


page 41

NLnetLabs

Delegation Signer (DS)

• Delegation Signer (DS) RR indicates that:– delegated zone is digitally signed– indicated key is used for the delegated zone

• Parent is authorative for the DS of the child’szone– Not for the NS record delegating the child’s zone!– DS should not be in the child’s zone


page 42

NLnetLabs

DS RDATA

• 16 bits: key tag

• 8 bits: algorithm

• 8 bits: digest type• 20 bytes: SHA-1 Digest

$ORIGIN ripe.net.disi.ripe.net. 3600 IN NS ns.disi.ripe.netdisi.ripe.net. 3600 IN DS 3112 5 1 ( 239af98b923c023371b52 1g23b92da12f42162b1a9 )


page 43

NLnetLabs

NSEC RDATA

• Points to the next domain name in the zone– also lists what are all the existing RRs for “name”– NSEC record for last name “wraps around” to first

name in zone

• N*32 bit type bit map• Used for authenticated denial-of-existence of data

– authenticated non-existence of TYPEs and labels

• Example:www.ripe.net. 3600 IN NSEC ripe.net. A RRSIG NSEC


page 44

NLnetLabs

NSEC Records

• NSEC RR provides proof of non-existence• If the servers response is Name Error (NXDOMAIN):

– One or more NSEC RRs indicate that the name or a wildcardexpansion does not exist

• If the servers response is NOERROR:– And empty answer section– The NSEC proves that the QTYPE did not exist

• More than one NSEC may be required in response– Wildcards

• NSEC records are generated by tools– Tools also order the zone


page 45

NLnetLabs

NSEC Walk

• NSEC records allow for zone enumeration• Providing privacy was not a requirement at the

time• Zone enumeration is a deployment barrier

• Work has started to study solutions– Requirements are gathered– If and when a solution is developed, it will co-exist

with DNSSEC-BIS !

6


page 46

NLnetLabs

Current Developments

• NSEC3 being tested– All RR names hashed– Hashed names are ordered– “opt-out” for unsecured delegations possibilities

• SHA1 to be deprecated– New hash for DS records– Overlap, no flag day


page 47

NLnetLabs

Other Keys in the DNS

• DNSKEY RR can only be used for DNSSEC– Keys for other applications need to use other RR types

• CERT– For X.509 certificates

• Application keys under discussion/development– IPSECKEY– SSHFP


Questions?

Summary

• DNSSEC not a PKI• Zone status

• New RRs: DNSKEY, RRSIG, NSEC, DS


Delegating SigningAuthority

Chains of Trust


page 50

NLnetLabs

Locally Secured Zones

• Key distribution does not scale!

net.

money.net. kids.net.

dopcorp

dev market dilbert

unixmacmarnick

nt

os.net.

com.

.

Out of band key-exchanges

Secure entry points


page 51

NLnetLabs

Using the DNS toDistribute Keys

• Secured islands make key distribution problematic

• Distributing keys through DNS:– Use one trusted key to establish authenticity of other

keys– Building chains of trust from the root down– Parents need to sign the keys of their children

• Only the root key needed in ideal world– Parents always delegate security to child


page 52

NLnetLabs

Key Problem

• Interaction with parent administratively expensive– Should only be done when needed– Bigger keys are better

• Signing zones should be fast– Memory restrictions– Space and time concerns– Smaller keys with short lifetimes are better


page 53

NLnetLabs

Key Functions

• Large keys are more secure– Can be used longer – Large signatures => large zonefiles – Signing and verifying computationally expensive

• Small keys are fast– Small signatures – Signing and verifying less expensive – Short lifetime


page 54

NLnetLabs

Key solution: MoreThan One Key

• RRsets are signed, not RRs• DS points to specific key

– Signature from that key over DNSKEY RRset transferstrust to all keys in DNSKEY RRset

• Key that DS points to only signs DNSKEY RRset– Key Signing Key (KSK)

• Other keys in DNSKEY RRset sign entire zone– Zone Signing Key (ZSK)

7


page 55

NLnetLabs

Initial Key Exchange

• Child needs to:– Send key signing keyset to parent

• Parent needs to:– Check childs zone

• for DNSKEY & RRSIGs

– Verify if key can be trusted– Generate DS RR


page 56

NLnetLabs

$ORIGIN .. DNSKEY (…) 5TQ3s… (8907) ; KSK DNSKEY (…) lasE5… (2983) ; ZSK

1

$ORIGIN net.

net. DNSKEY (…) q3dEw… (7834) ; KSK DNSKEY (…) 5TQ3s… (5612) ; ZSK

4

$ORIGIN ripe.net.

ripe.net. DNSKEY (…) rwx002… (4252) ; KSKDNSKEY (…) sovP42… (1111) ; ZSK

7

Walking the Chain ofTrust Locally configured

Trusted key: . 8907

2RRSIG DNSKEY (…) 8907 . 69Hw9..

net. DS 7834 3 1ab15… RRSIG DS (…) . 2983 3

ripe.net. DS 4252 3 1ab15… RRSIG DS (…) net. 5612

6

5 RRSIG DNSKEY (…) 7834 net. cMas...

8 RRSIG DNSKEY (…) 4252 ripe.net. 5t...

www.ripe.net. A 193.0.0.202 RRSIG A (…) 1111 ripe.net. a3...

9


page 57

NLnetLabs

• Data in zone can be trusted if signed by a Zone-Signing-Key

• Zone-Signing-Keys can be trusted if signed by a Key-Signing-Key

• Key-Signing-Key can be trusted if pointed to bytrusted DS record

• DS record can be trusted– if signed by the parents Zone-Signing-Keyor– DS or DNSKEY records can be trusted if exchanged out-

of-band and locally stored (Secure entry point)

Chain of TrustVerification, Summary


Questions?

Summary

• Scaling problem: secure islands• Zone signing key, key signing key

• Chain of trust


page 59

NLnetLabs

DDOS and the DNS

• Reflector attacks– Recently Open recursive servers used to

amplify traffic

– several Gbits/second traffic to criticalinfrastructure

– Source addresses at DDOS target are valid,packet format valid


page 60

NLnetLabs

resolver

ISPsrc: ispdst: resolver

src: resolverdst: isp

Answerfrom cache


page 61

NLnetLabs

target resolver

Zombie botnetsrc: target (spoof!)dst: resolver

src: resolverdst: target


page 62

NLnetLabs

an UDP problem

• DNS has nice amplification characteristics• ‘closing open resolvers’ helps, but

authoritative servers will do to• You make the packets smaller? We’ll just

wake up more zombies


page 63

NLnetLabs

Remedy: Ingressfiltering (BCP38)

Zombie botnet

Drop packets ifsource address is‘strange’ to thenetwork

8


page 64

NLnetLabs

Repeat: BCP38

• http://www.ietf.org/rfc/rfc2827.txt(BCP38)

“Network Ingress Filtering:Defeating Denial of Service Attacks which

employ IP Source Address Spoofing”

• Deploy on your own networks– Act responsibly in the Public Space

• Require deployment by others– Part of procurement procedures


Key Rollovers


page 66

NLnetLabs

Private Keys

• You have to keep your private key secret

• Private key can be stolen– Put the key on stand alone machines or on bastion

hosts behind firewalls and strong access control

• Private key reconstruction (crypto analysis)– Random number not random– Leakage of key material (DSA)– Brute force attacks


page 67

NLnetLabs

Key Rollovers

• Try to minimise impact– Short validity of signatures– Regular key rollover

• Remember: DNSKEYs do not have timestamps– the RRSIG over the DNSKEY has the timestamp

• Key rollover involves second party or parties:– State to be maintained during rollover– Operationally expensive


page 68

NLnetLabs

Timing of the ScheduledKey Rollover

• Don’t remove the old key while there servers arestill handing out the old DS RR

• New DS needs to be distributed to the slaves– Max time set by the SOA expiration time

• Old DS needs to have expired from caches– Set by the TTL of the original DS RR

• You (or your tool) can check if the master andslave have picked up the change


page 69

NLnetLabs

Timing Propertiestime

Authoritative Master Authoritative Slave Caching NameserverFoo TXT Old

Foo TXT NewPublication of new data

Query to slave followed by Caching

Foo TXT Old

Foo TXT Old

Zone transferFoo TXT New

Expiration From Cache

0

t1

t2

t3

Zon

e sy

nchr

oniz

atio

n

TT

L

Poof


page 70

NLnetLabs

Unscheduled RolloverProblems

• Needs out of band communication– With parent and pre-configured resolvers

• The parent needs to establish your identity again• How to protect child delegations?

– Unsecured?

• There will be a period that the stolen key can beused to generate seemingly secure data– There is no ‘revoke key’ mechanism

• Emergency procedure must be on the shelf


page 71

NLnetLabs

Key Rollover -Summary

• Generate new KSK• Sign with old and new KSKs• Wait for your servers + TTL of old DNSKEY RRset• Inform resolvers of the new key

– that have you as a trusted entry point

• Query for the parental DS and remember the TTL• Upload the new KSK or DS to the parent• Check if *all* parental servers have new DS• Wait another TTL before removing the old key


Questions?

Summary

• Key size and signature lifetimes• Key rollovers

• Emergency procedure

9


page 73

NLnetLabs

Questions?

introducing dnssec › ... › courses › cia › uva-dnssec-06.pdfdnssec evangineers of olaf: the...

Documents