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
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
9 April 2004
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
Outline
BackgroundDNS
DNSSEC
Problem StatementDesign Constraints
Alternative Solutions
Trust AuthoritiesDesign Problems
Resolver Algorithms
Aggressive Negative Caching
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
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
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
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
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
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.:
Q: www.example.net., IN, A
A: example.net. NS ns1.isp.com.
To ns1.isp.com.:
Q: www.example.net., IN, A
A: www.example.net. A 192.168.7.4
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
DNS Properties
Heterogeneous code
Simple protocol
Many subtletiesWildcards
CNAMEs
No authentication mechanismsEasy to forge answers
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
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
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
DNSSEC Outline
New RRs DNSKEYRRSIG (Resource Record SIGnature)DS (Delegation Signer)
Authentication ChainsMore new RRs
NSEC (Next SECure)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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?
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
Security PoliciesShould be up to the resolver...
Closest encloser trumps
Parent masks
Accept any success
Accept any failure
Accept any answer
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
Closest encloser trumpsNormal 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
“The longest applicable TA record takes precedence”
Validation fails.
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
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
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
Parent masksNormal 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
“The shortest applicable TA record takes precedence”
Validation fails.
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
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
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
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.:
example.net DNSKEY K3
child.example.net DS K4
child.example.net:
child.example.net DNSKEY K4
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
Accept any successNormal 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
“Keep looking until you find a success”
Validation succeeds.
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
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”)
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
Accept any failureNormal 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
“If any path from any TA fails validation, give an error”
Validation fails.
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
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.
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
Accept any answerNormal 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
“Try any TA (trust path) ”
Unpredictable result
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
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
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
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
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
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
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
Aggressive negative caching
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!
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
Aggressive negative caching
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Acknowledgements
Paul Vixie
Suzanne Woolf
Johan Ihren
Bill Manning
Rob Austein
Mark Andrews
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
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
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
The End
Questions?
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
Another scenarioNormal delegation chain
net.:
net DNSKEY K1
example.net NS (no DS)
example.net.:
example.net DNSKEY K2
child.example.net DS K3
child.example.net:
child.example.net DNSKEY K3
a.b.child.example.net DS K4
Trust Authority ta.com for .net:
ta.com:
example.ta.com TA K5
b.child.example.ta.com TA K6
TA says there's a b.child..., but the delegation tree doesn't!
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
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)
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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:
Top Related