The INI is a cooperative endeavor of: Electrical and Computer ...

1The INI is a cooperative endeavor of: Electrical and Computer Engineering School of Computer Science

Graduate School of Industrial Administration Heinz School of Public Policy

Deploying DNSSEC Without a Signed Root

Samuel Weiler

Spring 2004

The Information Networking Institute

is a cooperative endeavor of:

Electrical and Computer Engineering

School of Computer Science

Graduate School of Industrial Administration

Heinz School of Public Policy



Deploying DNSSEC Without a Signed Root

Samuel Weiler

9 April 2004



Outline

BackgroundDNS

DNSSEC

Problem StatementDesign Constraints

Alternative Solutions

Trust AuthoritiesDesign Problems

Resolver Algorithms

Aggressive Negative Caching



Domain Name System (DNS)

Global distributed database

Hierarchical namespace

Unique global root

Every domain name may have multiple resource record sets (RRsets)

cmu.edu MX 10 cmu-mx1.andrew.cmu.edu

cmu.edu MX 20 cmu-mx2.andrew.cmu.edu

cmu.edu A 128.2.11.43

.

net. com. us. edu.

example root-servers cmu mit

www cs ini

rupee



Zones and Delegations

Hierarchy is broken into zones

At a delegation, the parent zone contains a nameserver (NS) RRset for the child

In net.:

example.net NS ns1.isp.com

The child zone may have other Rrsets, also

In example.net.:

example.net NS ns1.isp.com

A 192.169.3.4

MX 10 mail.isp.com

.

net. com. us. edu.

example root-servers cmu mit

www cs ini

rupee



DNS Resolution

Start by asking the root's servers

Get a referral to a zone that is a closer match

Ask those servers, etc.

Each time, getting closer to the name asked for

Cache the results. The next query for a name in .net doesn't hit the root

To a.root-servers.net.:

Q: www.example.net., IN, A

A: net. NS a.gtld-servers.net.

To a.gtld-servers.net.:


A: example.net. NS ns1.isp.com.

To ns1.isp.com.:


A: www.example.net. A 192.168.7.4



DNS Properties

Heterogeneous code

Simple protocol

Many subtletiesWildcards

CNAMEs

No authentication mechanismsEasy to forge answers



DNS Security (DNSSEC)

Authenticates zone data using public key signaturesAuthenticates data, not transactions (TSIG)

Start with a well-known public key for a high level zone (ie. .net or the root)

“Certificate” chain authenticates keys of each zone in the delegation chain

Provides NO confidentiality

No revocation mechanismRelies on short “certificate” lifetimes



DNSSEC Outline

New RRs DNSKEYRRSIG (Resource Record SIGnature)DS (Delegation Signer)

Authentication ChainsMore new RRs

NSEC (Next SECure)



DNSKEY Resource Record

Stores the public half of an asymmetric key pair

Belongs to the ZONE, not the server

Stored at the zone apex (along with the SOA, NS, A?, MX?)

May have multiple DNSKEYs per zone

Example example.net 3600 IN DNSKEY 256 3 3 AJXxPAbJ+2eDT88mcWRc2fjrio/Ho



RRSIG Resource Record

Public key signature on one authoritative RRset made with one DNSKEY

Authenticates that RRset

Limited validity interval

Exampleexample.net 3600 RRSIG NS 3 2 3600 20040319180202 20040218180202

27036 example.net. AEOAhHAPDOSKjeOR1sOYBEaDkWtk=

NS: RRset that this RRSIG applies to3: Algorithm2: Number of labels in the name signed (used to detect wildcard answers)3600: original TTL20040319180202: signature expiration, YYYYMMDDHHmmSS in UTC20040218180202: signature inception27036: key tag of the DNSKEY used to make this RRSIGexample.net: signer name



Delegation Signer (DS) Resource Record

Indicates which DNSKEY(s) the child may use– Contains a hash of that DNSKEY

Establish an expectation that the child will be signed

Appears at a delegation in the parent zone ONLY

Also proves the existence of a delegation

Example

example.net. 3600 IN NS ns1.isp.com. example.net. 3600 IN DS 27374 599909F9B767FBD6...B758D



Authentication Chains

Alternating sequence of DNSKEY and DS RRsStart with a “trusted” DNSKEY

Preconfigured

Need secured out-of-band transfer

That key signs a zone’s DNSKEYset, authenticating other DNSKEYs

Any of those DNSKEYs can sign other data in the zoneDS records at the parent show which DNSKEYs may

sign a child’s DNSKEYsetEnd at the DNSKEY that authenticates the given RR



Authentication Chains Example

.

net.

example.net

[Kk1, Kz2], SIG Kk1

DS(Kk3), SIG(Kz2)

[Kk3, Kz4], SIG Kk3

DS(Kk5), SIG(Kz4)

[Kk5, Kz6], SIG Kk5

SOA, SIG(Kz6)

Trusted



Next SECure (NSEC) Resource Record

Proves what data is (and isn’t) in the zone

Lists the RR types present at a nameExample a.example.net. 3600 NSEC b.example.net. NS RRSIG NSEC

Identifies the next name in the (sorted) zoneNSEC for the last name points to the SOA

z.example.net. 3600 NSEC example.net. NS RRSIG NSEC SOA DNSKEY

Sent withNXDOMAIN answersWildcard answers (to prove that there’s no exact match)Unsecure delegations (to prove that there’s no DS)NSECs with the same name exist at parent and child

a.example.net. 3600 NSEC test.a.example.net. A MX RRSIG NSEC



Validation Results

Secure/valid: starting at a preconfigured trusted key, there is a working chain of DNSKEYs, RRSIGs, and maybe DSs down to the data

Verifiably unsecure: starting at a preconfigured trusted key, there is a working chain of DNSKEYs, RRSIGs, and (perhaps) DSs down to some delegation at which there is a valid NSEC proving that no DS exists (an unsecure delegation)

Alternatively: the resolver has no preconfigured key (for that portion of the namespace)

Bad/bogus: Having expected valid data, something didn't work



Hurdles to DNSSEC Deployment

Demand for securityWill fragility sell?

ScalingDNSSEC adds:

one NSEC RR per name

one RRSIG RR per RRset

Overall: x5-10 zone growth AND response size growth

Extra managementMore data passed between children and parents

Preconfiguration of trusted keys

Regularly resigning the zone

Key management



Hurdles to DNSSEC Utility

Scaling issues keep large zones (TLDs) from signing

Political issues keep the root from signingNo consensus on who should hold the key(s)

Leaf zones have few hurdles to signingOnly useful if resolvers preconfigure keys for each of those zones

Not as bad as NxN shared secret distribution

Still too much to maintain



Problem Statement

Provide a mechanism for resolvers to validate signed zones without1) Maintaining separate trusted keys for each zone2) Requiring the cooperation of those zones' ancestors



Design Constraints

Deployable!

Simple code

ScalableCost directly proportional to number of clients

Cost directly proportional to number of secured zones

Able to distribute load

SafeCause no harm to non-participants (including the ancestors of

participating nodes, such as the root)

No excessive load on the network

No gotchas

No protocol perturbations



Outline

Alternative Solutions & Related WorkOut of band

SIG@child

Alternate tree

Overlay tree

Opt-in

FMESHD

Trust AuthoritiesConflicts with the main tree

Resolver algorithms

Scaling enhancements

Aggressive Negative Caching

Closest Encloser Answers



Out of Band

Separate database for trust statements

Pros:Simple, understandable

No interactions with legacy DNS resolvers

Cons:No use of existing DNS caches

Build own caching, or have difficulties scaling

May not pass through firewalls as easily as DNS packets



SIG@child

Store trust statements in the zones to which they refer (ie. SSL certificates)

Pros:Scales – no longer need to run a centralized service

Cons: A zone can't prove that it isn't supposed to be signed

No revocation mechanism – assumes long-lived certificates (SSL) or frequent updates to the certificate

Done before: SIG@child (RFC2535)Parent had records for each zone that was NOT signed

Scaling benefit lost – resolvers still hit the parent



Alternate tree

Separate root (or subtree)Sign the root (just not the real one)Delegations initially the same as in the real treeAs zones want to be added, add their ancestors to the alternate tree and

sign them.

Pros:NO resolver changes (just change root.hints)NO protocol changes

Cons:History of alternate roots not getting wide adoptionRequires each ancestor zone to be available to the alternate tree operator

Requires the cooperation of zone operatorViolates the design constraints



Overlay tree

Similar to the “alternate tree”, but only include secured zonesResolvers first query overlay tree. If they find that the sought data doesn't

exist there, look in the main tree.

No way to prove that data should not exist

Allows insertion attacks

Messy logic



Opt-in

VeriSign proposal to allow unsecure (no DS record) delegations to be unsignedWould have relieved scaling pressure on .com

Zone would grow only as secure delegations added

Required protocol change

Weakened security guarantees

Advantaged one player

Died in the IETF



FMESHD

DARPA project that aimed to join “islands of trust”

Idea: allow all zones to make trust statements about all other zones

Transitive trust (ie. PGP)Finding paths tractable in memory

Not tractable when each piece of data must be fetched in separate queries over the network

Need to bound the searching

Never happened



Trust Authorities

DS-like RRs (TA RRs)

Well-known signed zone, not the parent

Targets some zoneExample: a TA for .org at the name dnssec.nl.

The TA record for riaa.org would be named riaa.dnssec.nl.

Presence of a TA RR proves that the relevant zone should be signed

Absence of a TA RR (proven by an NSEC) says nothing Assume zones to be unsigned until proven otherwise

TA zone need not enumerate all names in its target, not even all secured ones



Single-zone, Single-label TAs

Incremental step in development

Marginally simpler

Limits utility of TAsDNS allows multiple label delegations (ie. dnssec.ini.cmu.edu could be a

delegation from cmu.edu even if ini.cmu.edu is not a delegation)



Hierarchical Trust Authorities

Entire DNS hierachy can be targeted

Allow delegations within the TA tree (using DS records)Share load among groups of authoritative servers

Share administrative control

Example 1: TA for .net at ta.comexample.ta.com. TA hash(K1) example.net DNSKEY K1

ta.com. TA hash(K2) net DNSKEY K2

Example 2: TA for . at trust.comcnn.com.trust.com. TA hash(K3) cnn.com DNSKEY K3

Pressence of a TA record says that the relevant zone should be signed



Why a new RR type?

DS and TXT already exist

Overloading resource records bad (RFC3445)May conflict with other users of those RRs

DS RR has very special semanticsOnly record to appear ONLY at a parent

Has caused numerous problems before

Reusing it would be risky

Using DS in hierarchical TAs to spread load



Expected problemsNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:

example.net DNSKEY K3

child.example.net DS K4

child.example.net:

child.example.net DNSKEY K4

Trust Authority ta.com for .net:

ta.com:

ta.com TA K1

example.ta.com TA K3

child.example.ta.com TA K5

Resolver has no preconfigured keys except for ta.com.

Which TA RR (which trust path) takes precedence?



Security PoliciesShould be up to the resolver...

Closest encloser trumps

Parent masks

Accept any success

Accept any failure

Accept any answer



Closest encloser trumpsNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:



child.example.net:



ta.com:

ta.com TA K1



“The longest applicable TA record takes precedence”

Validation fails.



Closest encloser trumps, resolver alg.

Always have to check the TA to see if there's a closer encloser.

Query: www.child.example.net A

Ask TA: www.child.example.ta.com. TA ?

child.example.ta.com. TA?

example.ta.com. TA?

ta.com. TA? (would apply to .net)

TA servers get hit (multiple times) on every (unique) query Queries = #resolvers * queries/resolver * labels/name



Parent masksNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:



child.example.net:



ta.com:

ta.com TA K1



“The shortest applicable TA record takes precedence”

Validation fails.



Parent masks, resolver algorithm

Start with the shortest label

Query: www.child.example.net A

Ask TA: ta.com. TA?

example.ta.com. TA?

child.example.ta.com. TA?

www.child.example.ta.com. TA ?

TA RRs get cached

Worst case (nothing signed):Queries = #resolvers * queries/resolver * labels/name

Best case (root signed):Queries = #resolvers



Parent masks, fallout

There cannot be TA records for any name below another TA record

Can't skip aroundholes in the tree

Doesn't satisfy designgoals

net.:

net DNSKEY K1

(no DS for example.net.)

example.net.:



child.example.net:




Accept any successNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:



child.example.net:



ta.com:

ta.com TA K1



“Keep looking until you find a success”

Validation succeeds.



Accept any success, resolver algorithm

Most liberal policy

Test trust paths in any orderTo minimize network load, try cached TAs first

Must exhaustively search for a good one

Worst case (nothing signed):Queries = #resolvers * queries/resolver * labels/name

Best case (root signed):Queries = #resolvers

(Same as “parent masks”)



Accept any failureNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:



child.example.net:



ta.com:

ta.com TA K1



“If any path from any TA fails validation, give an error”

Validation fails.



Accept any failure, resolver algorithm

Strictest policy; results in brittleness

Test trust paths in any orderTo minimize network load, try cached TAs first

Must exhaustively search for a bad one

Worst case (all paths validate):Queries = #resolvers * queries/resolver * labels/name

Best case (root TA broken):Queries = #resolvers

Efficient when things are broken.



Accept any answerNormal delegation chain

net.:

net DNSKEY K1

example.net DS K2

example.net.:



child.example.net:



ta.com:

ta.com TA K1



“Try any TA (trust path) ”

Unpredictable result



Accept any answer, resolver algorithm

To minimize load, try cached TAs first

Effectively “parent masks” but not as predictable

Answer depends on what's cachedBreaks DNS's “loose consistency”

Worst case (no TA records):Queries = #resolvers * queries/resolver * labels/name

Best case (a TA RR for the root exists)Queries = #resolvers



Policy comparison

Closest encloser trumps: All cases: Queries = #resolvers * queries/resolver * labels/name

Parent masks: doesn't satisfy constraints

Accept any success:Worst case: Queries = #resolvers * queries/resolver * labels/name

Best case: Queries = #resolvers

Accept any failure: brittle

Accept any answer: inconsistent

Queries/resolver term troubling



Aggressive negative caching

NSEC RRs indicate that nothing exists in some span

a.example.net. NSEC f.example.net. ...

Proves that b.example.net. does not exist

DNS caches answers by the name asked for, NOT the name of data returnedA subsequent query for d.example.net. would not be answered from the

cache

Could change thatRestructure cache

Synthesize negative answers based on NSECs received in response to other queries




Benefit: caps the number of queriesOnce the entire NSEC chain is cached, no queries for non-existent TA

records

Cap is 2*number of records

One for the NSEC

One for the TA at that name

Useful when the TA zone has very few records

Query load scales as TA records are added!




ProblemWhat if NSECs are overreaching?

The next name field is outside the zone

Example: www.example.net NSEC .net

Resolvers should be checking that the next name is within the scope of the signing zone

Otherwise, various attacks possibleRegister aaaa.com

Generate: aaaa.com NSEC zzzz.com

Spoof cnn.com out of existence

Old risk, new danger

Before, an attacker would have to substitute that answer explicitly to cause misbehavior

Now, misconfiguration can cause misbehavior



Closest encloser (label stripping)

“Accept any succes” had worst case behavior ofQueries = #resolvers * queries/resolver * labels/name

Why labels/name?

Can't always get all TAs from one serverQ: www.child.example.net. TA?

A: child.example.net. TA ....

example.net. TA .... (could be on another server)

net. TA ....

And can't ask just at delegations (can't trust the unsigned delegation tree to identify delegations)

Slight improvement possible



Closest encloser answers

Resolvers ask for the longest TA record

TA authoritative servers give back all possible TAsAnd proofs that any others don't exist

Slight protocol perturbationExcept for delegations, all answers have same name as the

QNAME

Put the extra TA records in the “additional” section of the DNS response

More testing needed (difficult)

Depends on security policyForces choice of policy



Final design

Hierarchical TA

“Accept any valid answer” resolver security policyLiberal policy makes for fewer failures and encourages

adoptionRequires exhaustive search for TA records until one

worksPerformance improves as more zones are signed

Aggressive negative cachingDramatically reduces TA server load in early

deploymentAllows TA server load to grow slowly



Performance

Maximum query load is:#resolvers * Min(queries/resolver, entries in TA) * #labels/name

Performance improves as zones (esp. higher level zones) are signed. Best case load:

#resolvers

The only protocol perturbation is aggressive negative cachingNo change in security properties



Future work

Closest encloser answersChoose a policy now (“accept any success”)

Multiple TAs and complex security policiesThresholds (3 TAs configured; if one fails, the other two must succeed to

result in a validation)

Augment/check the main delegation tree



Deployment

Strong consensus that some form of bootstrapping is needed for DNSSEC

Opt-in seems to be dead

Root and TLDs are unlikely to be signed soon

Infrastructure name server operators and resolver implementers interested in this design



Acknowledgements

Paul Vixie

Suzanne Woolf

Johan Ihren

Bill Manning

Rob Austein

Mark Andrews



Lessons Learned

Difficult to retrofit security onto something as widely deployed as DNS. Too much heterogeneity.

Enforcing (checking) security is about rejecting states. Security introduces brittleness.

DNSSEC is useless unless you create an expectation that data will be secured. Otherwise, you're subject to degradation attacks

Policy can drive algorithm choice, which can drive protocol design

Security is not survivability



The End

Questions?



Another scenarioNormal delegation chain

net.:

net DNSKEY K1

example.net NS (no DS)

example.net.:



child.example.net:


a.b.child.example.net DS K4


ta.com:


b.child.example.ta.com TA K6

TA says there's a b.child..., but the delegation tree doesn't!



DS Lameness Bug (Aug 2002)

DS was the first RR to appear only at the parentBefore, NS was the only RR to appear on the parent's side of a zone cut

The child had an NS RRset, too

The child could answer any question that ended with it's name

Answer, NXDOMAIN, or referral

How does the child answer a query for DS?Referral to root

Older (non-DS-aware) resolvers said servers doing that were “lame”

Quit talking to those servers

Zone fell off the net

AnswerChange the response to something non-fatal (a “transient” error)



DS Grandparent Problem (Oct 2002)

Server 1 authoritative for:. (the root)root-servers.net.

Server 2 authoritative for:net.

Query:root-servers.net. DS? (stored in net., at server two)

Client 1, modern DS-aware code:Directs the query to the root (server1)Needs a referral to net. (server2)

Client 2, legacy code:Having previously done a lookup for a.root-servers.net's A record, has

cached the root-servers.net NS. Directs the query to root-servers.net. (server1)If it gets a referral, triggers the lameness bug



DS Grandparent Problem

Incompatible needs:

Client 1, modern:

If it gets an error (instead of a referral) how does it find .net?

Client 2, legacy code:

If it gets a referral, triggers the lameness bug

Answer:

Legacy code can't be changed: give the error

Find another way for the modern code to find the DS

DS is in root-servers.net.'s parent, but what's the parent?



DS Grandparent Problem

Delegations can be multi-labelCan't just strip one label from the QNAME to find the

parent

New algorithm: keep stripping labels until you find the parent



NSEC Problem (Jakob's bug, Jan 2003)

In RFC2535, NXT (the predecessor of NSEC) was only returned as part of a negative answer

With DS, NXT is returned on any unsecure referral (to prove that there's no DS)

Some code saw any NXT, assumed it meant the name didn't exist, and quit

Answer: change the typecodes (RFC3755)NXT-->NSECSIG-->RRSIGKEY-->DNSKEY



Degradation Attack (May 2003?)

Safety property: properly signing a zone should not cause a zone to fall off the network

DNSSEC allows multiple public-key crypto algorithms

Experimental/private algorithms Resolvers might not support them all

In RFC2535, each RRset had to have a SIG, made by ANY of the zone's DNSKEYs

If the only SIG on an RRset is from an unsupported algorithm, can't throw a hard error

Would violate the safety property



Degradation Attack

Attack:

substitute bogus data and a broken RRSIG made by some obscure algorithm

Resolver can't give a hard error

Prevention: never include an DNSKEY of an obscure algorithm in the DNSKEYset

Prevents experimentation with new algorithmsPrevents replacement of algorithms if one is

compromised



Degradation Attack

Answer:

Change the expectation

Rather than: each RRset must be signed by ANY of the DNSKEYs

Use: each RRset must be signed by at least one DNSKEY of EACH algorithm in the DNSKEYset

Similar rules for DS/DNSKEY



INI Powerpoint Layout

This is the recommended layout for INI Presentations. TEXT

The chosen font is Arial. Align all text to the left. FONT SIZES

> 16 or 18 for body text- navy blue> 24 or 20 Bold for sub-heads- navy blue> 32 bold for main titles- solid white on the gray bar

Main titles for each slide should fit on one line (Arial 32 bold). The slides look cramped with 2-line titles. A power-point slide should present basic information, that’s quick to scan and easy to read.

COLORS Slide Titles use solid White. Use Navy Blue for all other text. Bullets and top banner uses a 40% Gray. Here are some recommended highlight colors. Use as needed:

The INI is a cooperative endeavor of: Electrical and Computer ...

Documents

Transcript of The INI is a cooperative endeavor of: Electrical and Computer ...