Samuel Weiler Spring 2004 Deploying DNSSEC Without a Signed Root The Information Networking Institute  is  a cooperative e...
Deploying DNSSEC Without a Signed Root <ul><ul><li>Samuel Weiler </li></ul></ul><ul><ul><li>9 April 2004 </li></ul></ul>
Outline <ul><li>Background </li></ul><ul><ul><li>DNS </li></ul></ul><ul><ul><li>DNSSEC </li></ul></ul><ul><li>Problem Stat...
Domain Name System (DNS) <ul><li>Global distributed database </li></ul><ul><li>Hierarchical namespace </li></ul><ul><li>Un...
Zones and Delegations <ul><li>Hierarchy is broken into  zones </li></ul><ul><li>At a  delegation,  the  parent zone  conta...
DNS Resolution <ul><li>Start by asking the root's servers </li></ul><ul><li>Get a  referral  to a zone that is a closer ma...
DNS Properties <ul><li>Heterogeneous code </li></ul><ul><li>Simple protocol </li></ul><ul><li>Many subtleties </li></ul><u...
DNS Security (DNSSEC) <ul><li>Authenticates zone data using public key signatures </li></ul><ul><ul><li>Authenticates data...
DNSSEC Outline <ul><li>New RRs  </li></ul><ul><ul><li>DNSKEY </li></ul></ul><ul><ul><li>RRSIG (Resource Record SIGnature) ...
DNSKEY Resource Record <ul><li>Stores the public half of an asymmetric key pair </li></ul><ul><li>Belongs to the ZONE, not...
RRSIG Resource Record <ul><li>Public key signature on one authoritative RRset made with one DNSKEY </li></ul><ul><li>Authe...
Delegation Signer (DS) Resource Record <ul><li>Indicates which DNSKEY(s) the child may use </li></ul><ul><ul><li>Contains ...
Authentication Chains <ul><li>Alternating sequence of DNSKEY and DS RRs </li></ul><ul><ul><li>Start with a “trusted” DNSKE...
Authentication Chains Example [K k 1, K z 2], SIG K k 1 DS(K k 3), SIG(K z 2) [K k 3, K z 4], SIG K k 3 DS(K k 5), SIG(K z...
Next SECure (NSEC) Resource Record <ul><li>Proves what data is (and isn’t) in the zone </li></ul><ul><ul><li>Lists the RR ...
Validation Results <ul><li>Secure/valid: starting at a preconfigured trusted key, there is a working chain of DNSKEYs, RRS...
Hurdles to DNSSEC Deployment <ul><li>Demand for security </li></ul><ul><ul><li>Will fragility sell? </li></ul></ul><ul><li...
Hurdles to DNSSEC Utility <ul><li>Scaling issues keep large zones (TLDs) from signing </li></ul><ul><li>Political issues k...
Problem Statement <ul><li>Provide a mechanism for resolvers to validate signed zones without </li></ul><ul><ul><li>1) Main...
Design Constraints <ul><li>Deployable! </li></ul><ul><li>Simple code </li></ul><ul><li>Scalable </li></ul><ul><ul><li>Cost...
Outline <ul><li>Alternative Solutions & Related Work </li></ul><ul><ul><li>Out of band </li></ul></ul><ul><ul><li>[email_a...
Out of Band <ul><li>Separate database for trust statements </li></ul><ul><li>Pros: </li></ul><ul><ul><li>Simple, understan...
[email_address] <ul><li>Store trust statements in the zones to which they refer (ie. SSL certificates) </li></ul><ul><li>P...
Alternate tree <ul><li>Separate root (or subtree) </li></ul><ul><ul><li>Sign the root (just not the real one) </li></ul></...
Overlay tree <ul><li>Similar to the “alternate tree”, but only include secured zones </li></ul><ul><ul><li>Resolvers first...
Opt-in <ul><li>VeriSign proposal to allow unsecure (no DS record) delegations to be unsigned </li></ul><ul><ul><li>Would h...
FMESHD <ul><li>DARPA project that aimed to join “islands of trust” </li></ul><ul><li>Idea: allow all zones to make trust s...
Trust Authorities <ul><li>DS-like RRs (TA RRs) </li></ul><ul><li>Well-known signed zone, not the parent </li></ul><ul><li>...
Single-zone, Single-label TAs <ul><li>Incremental step in development </li></ul><ul><li>Marginally simpler </li></ul><ul><...
Hierarchical Trust Authorities <ul><li>Entire DNS hierachy can be targeted  </li></ul><ul><li>Allow delegations within the...
Why a new RR type? <ul><li>DS and TXT already exist </li></ul><ul><li>Overloading resource records bad (RFC3445) </li></ul...
Expected problems <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul>...
Security Policies <ul><li>Should be up to the resolver... </li></ul><ul><li>Closest encloser trumps </li></ul><ul><li>Pare...
Closest encloser trumps <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li...
Closest encloser trumps, resolver alg. <ul><li>Always have to check the TA to see if there's a closer encloser. </li></ul>...
Parent masks <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul></ul>...
Parent masks, resolver algorithm <ul><li>Start with the shortest label </li></ul><ul><li>Query: www.child.example.net A </...
Parent masks, fallout <ul><li>There cannot be TA records for any name below another TA record </li></ul><ul><li>Can't skip...
Accept any success <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul...
Accept any success, resolver algorithm <ul><li>Most liberal policy </li></ul><ul><li>Test trust paths in any order </li></...
Accept any failure <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul...
Accept any failure, resolver algorithm <ul><li>Strictest policy; results in brittleness </li></ul><ul><li>Test trust paths...
Accept any answer <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul>...
Accept any answer, resolver algorithm <ul><li>To minimize load, try cached TAs first </li></ul><ul><li>Effectively “parent...
Policy comparison <ul><li>Closest encloser trumps:  </li></ul><ul><ul><li>All cases: Queries = #resolvers * queries/resolv...
Aggressive negative caching <ul><li>NSEC RRs indicate that nothing exists in some span </li></ul><ul><li>a.example.net.  N...
Aggressive negative caching <ul><li>Benefit: caps the number of queries </li></ul><ul><ul><li>Once the entire NSEC chain i...
Aggressive negative caching <ul><li>Problem </li></ul><ul><ul><li>What if NSECs are overreaching? </li></ul></ul><ul><ul><...
Closest encloser (label stripping) <ul><li>“ Accept any succes” had worst case behavior of </li></ul><ul><ul><li>Queries =...
Closest encloser answers <ul><li>Resolvers ask for the longest TA record </li></ul><ul><li>TA authoritative servers give b...
Final design <ul><li>Hierarchical TA </li></ul><ul><li>“ Accept any valid answer” resolver security policy </li></ul><ul><...
Performance <ul><li>Maximum query load is: </li></ul><ul><li>#resolvers * Min(queries/resolver, entries in TA) * #labels/n...
Future work <ul><li>Closest encloser answers </li></ul><ul><ul><li>Choose a policy now (“accept any success”) </li></ul></...
Deployment <ul><li>Strong consensus that some form of bootstrapping is needed for DNSSEC </li></ul><ul><ul><li>Opt-in seem...
Acknowledgements <ul><li>Paul Vixie </li></ul><ul><li>Suzanne Woolf </li></ul><ul><li>Johan Ihren </li></ul><ul><li>Bill M...
Lessons Learned <ul><li>Difficult to retrofit security onto something as widely deployed as DNS.  Too much heterogeneity. ...
The End <ul><li>Questions? </li></ul>
Another scenario <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net  DNSKEY  K1 </li></ul><...
DS Lameness Bug (Aug 2002) <ul><li>DS was the first RR to appear only at the parent </li></ul><ul><ul><li>Before, NS was t...
DS Grandparent Problem (Oct 2002) <ul><li>Server 1 authoritative for: </li></ul><ul><ul><li>. (the root) </li></ul></ul><u...
DS Grandparent Problem <ul><li>Incompatible needs: </li></ul><ul><ul><li>Client 1, modern: </li></ul></ul><ul><ul><ul><li>...
DS Grandparent Problem <ul><li>Delegations can be multi-label </li></ul><ul><ul><li>Can't just strip one label from the QN...
NSEC Problem (Jakob's bug, Jan 2003) <ul><li>In RFC2535, NXT (the predecessor of NSEC) was only returned as part of a nega...
Degradation Attack (May 2003?) <ul><li>Safety property: properly signing a zone should not cause a zone to fall off the ne...
Degradation Attack <ul><li>Attack:  </li></ul><ul><ul><li>substitute bogus data  </li></ul></ul><ul><ul><li>and a broken R...
Degradation Attack <ul><li>Answer: </li></ul><ul><ul><li>Change the expectation </li></ul></ul><ul><ul><li>Rather than: ea...
INI Powerpoint Layout <ul><li>This is the recommended layout for INI Presentations.  </li></ul><ul><li>TEXT </li></ul><ul>...
Upcoming SlideShare
Loading in...5
×

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

291
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
291
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Samuel Weiler Spring 2004 Deploying DNSSEC Without a Signed Root 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
  2. 2. Deploying DNSSEC Without a Signed Root <ul><ul><li>Samuel Weiler </li></ul></ul><ul><ul><li>9 April 2004 </li></ul></ul>
  3. 3. Outline <ul><li>Background </li></ul><ul><ul><li>DNS </li></ul></ul><ul><ul><li>DNSSEC </li></ul></ul><ul><li>Problem Statement </li></ul><ul><ul><li>Design Constraints </li></ul></ul><ul><li>Alternative Solutions </li></ul><ul><li>Trust Authorities </li></ul><ul><ul><li>Design Problems </li></ul></ul><ul><ul><li>Resolver Algorithms </li></ul></ul><ul><ul><li>Aggressive Negative Caching </li></ul></ul>
  4. 4. Domain Name System (DNS) <ul><li>Global distributed database </li></ul><ul><li>Hierarchical namespace </li></ul><ul><li>Unique global root </li></ul><ul><li>Every domain name may have multiple resource record sets (RRsets) </li></ul><ul><li>cmu.edu MX 10 cmu-mx1.andrew.cmu.edu </li></ul><ul><li>cmu.edu MX 20 cmu-mx2.andrew.cmu.edu </li></ul><ul><li>cmu.edu A 128.2.11.43 </li></ul>. net. com. us. edu. example root-servers cmu mit www cs ini rupee
  5. 5. Zones and Delegations <ul><li>Hierarchy is broken into zones </li></ul><ul><li>At a delegation, the parent zone contains a nameserver (NS) RRset for the child </li></ul><ul><li>In net.: </li></ul><ul><ul><li>example.net NS ns1.isp.com </li></ul></ul><ul><li>The child zone may have other Rrsets, also </li></ul><ul><li>In example.net.: </li></ul><ul><ul><li>example.net NS ns1.isp.com </li></ul></ul><ul><ul><li>A 192.169.3.4 </li></ul></ul><ul><ul><li>MX 10 mail.isp.com </li></ul></ul>. net. com. us. edu. example root-servers cmu mit www cs ini rupee
  6. 6. DNS Resolution <ul><li>Start by asking the root's servers </li></ul><ul><li>Get a referral to a zone that is a closer match </li></ul><ul><li>Ask those servers, etc. </li></ul><ul><li>Each time, getting closer to the name asked for </li></ul><ul><li>Cache the results. The next query for a name in .net doesn't hit the root </li></ul>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
  7. 7. DNS Properties <ul><li>Heterogeneous code </li></ul><ul><li>Simple protocol </li></ul><ul><li>Many subtleties </li></ul><ul><ul><li>Wildcards </li></ul></ul><ul><ul><li>CNAMEs </li></ul></ul><ul><li>No authentication mechanisms </li></ul><ul><ul><li>Easy to forge answers </li></ul></ul>
  8. 8. DNS Security (DNSSEC) <ul><li>Authenticates zone data using public key signatures </li></ul><ul><ul><li>Authenticates data, not transactions (TSIG) </li></ul></ul><ul><li>Start with a well-known public key for a high level zone (ie. .net or the root) </li></ul><ul><li>“ Certificate” chain authenticates keys of each zone in the delegation chain </li></ul><ul><li>Provides NO confidentiality </li></ul><ul><li>No revocation mechanism </li></ul><ul><ul><li>Relies on short “certificate” lifetimes </li></ul></ul>
  9. 9. DNSSEC Outline <ul><li>New RRs </li></ul><ul><ul><li>DNSKEY </li></ul></ul><ul><ul><li>RRSIG (Resource Record SIGnature) </li></ul></ul><ul><ul><li>DS (Delegation Signer) </li></ul></ul><ul><li>Authentication Chains </li></ul><ul><li>More new RRs </li></ul><ul><ul><li>NSEC (Next SECure) </li></ul></ul>
  10. 10. DNSKEY Resource Record <ul><li>Stores the public half of an asymmetric key pair </li></ul><ul><li>Belongs to the ZONE, not the server </li></ul><ul><li>Stored at the zone apex (along with the SOA, NS, A?, MX?) </li></ul><ul><li>May have multiple DNSKEYs per zone </li></ul><ul><li>Example </li></ul><ul><li>example.net 3600 IN DNSKEY 256 3 3 AJXxPAbJ+2eDT88mcWRc2fjrio/Ho </li></ul>
  11. 11. RRSIG Resource Record <ul><li>Public key signature on one authoritative RRset made with one DNSKEY </li></ul><ul><li>Authenticates that RRset </li></ul><ul><li>Limited validity interval </li></ul><ul><li>Example </li></ul><ul><li>example.net 3600 RRSIG NS 3 2 3600 20040319180202 20040218180202 27036 example.net. AEOAhHAPDOSKjeOR1sOYBEaDkWtk= </li></ul><ul><li>NS: RRset that this RRSIG applies to </li></ul><ul><li>3: Algorithm </li></ul><ul><li>2: Number of labels in the name signed (used to detect wildcard answers) </li></ul><ul><li>3600: original TTL </li></ul><ul><li>20040319180202: signature expiration, YYYYMMDDHHmmSS in UTC </li></ul><ul><li>20040218180202: signature inception </li></ul><ul><li>27036: key tag of the DNSKEY used to make this RRSIG </li></ul><ul><li>example.net: signer name </li></ul>
  12. 12. Delegation Signer (DS) Resource Record <ul><li>Indicates which DNSKEY(s) the child may use </li></ul><ul><ul><li>Contains a hash of that DNSKEY </li></ul></ul><ul><li>Establish an expectation that the child will be signed </li></ul><ul><li>Appears at a delegation in the parent zone ONLY </li></ul><ul><li>Also proves the existence of a delegation </li></ul><ul><li>Example </li></ul><ul><li>example.net. 3600 IN NS ns1.isp.com. </li></ul><ul><li>example.net. 3600 IN DS 27374 599909F9B767FBD6...B758D </li></ul>
  13. 13. Authentication Chains <ul><li>Alternating sequence of DNSKEY and DS RRs </li></ul><ul><ul><li>Start with a “trusted” DNSKEY </li></ul></ul><ul><ul><ul><li>Preconfigured </li></ul></ul></ul><ul><ul><ul><li>Need secured out-of-band transfer </li></ul></ul></ul><ul><ul><li>That key signs a zone’s DNSKEYset, authenticating other DNSKEYs </li></ul></ul><ul><ul><li>Any of those DNSKEYs can sign other data in the zone </li></ul></ul><ul><ul><li>DS records at the parent show which DNSKEYs may sign a child’s DNSKEYset </li></ul></ul><ul><ul><li>End at the DNSKEY that authenticates the given RR </li></ul></ul>
  14. 14. Authentication Chains Example [K k 1, K z 2], SIG K k 1 DS(K k 3), SIG(K z 2) [K k 3, K z 4], SIG K k 3 DS(K k 5), SIG(K z 4) [K k 5, K z 6], SIG K k 5 SOA, SIG(K z 6) . net. example.net Trusted
  15. 15. Next SECure (NSEC) Resource Record <ul><li>Proves what data is (and isn’t) in the zone </li></ul><ul><ul><li>Lists the RR types present at a name </li></ul></ul><ul><li>Example </li></ul><ul><li>a.example.net. 3600 NSEC b.example.net. NS RRSIG NSEC </li></ul><ul><li>Identifies the next name in the (sorted) zone </li></ul><ul><ul><li>NSEC for the last name points to the SOA </li></ul></ul><ul><li>z.example.net. 3600 NSEC example.net. NS RRSIG NSEC SOA DNSKEY </li></ul><ul><li>Sent with </li></ul><ul><ul><li>NXDOMAIN answers </li></ul></ul><ul><ul><li>Wildcard answers (to prove that there’s no exact match) </li></ul></ul><ul><ul><li>Unsecure delegations (to prove that there’s no DS) </li></ul></ul><ul><ul><li>NSECs with the same name exist at parent and child </li></ul></ul><ul><li>a.example.net. 3600 NSEC test.a.example.net. A MX RRSIG NSEC </li></ul>
  16. 16. Validation Results <ul><li>Secure/valid: starting at a preconfigured trusted key, there is a working chain of DNSKEYs, RRSIGs, and maybe DSs down to the data </li></ul><ul><li>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) </li></ul><ul><ul><li>Alternatively: the resolver has no preconfigured key (for that portion of the namespace) </li></ul></ul><ul><li>Bad/bogus: Having expected valid data, something didn't work </li></ul>
  17. 17. Hurdles to DNSSEC Deployment <ul><li>Demand for security </li></ul><ul><ul><li>Will fragility sell? </li></ul></ul><ul><li>Scaling </li></ul><ul><ul><li>DNSSEC adds: </li></ul></ul><ul><ul><ul><li>one NSEC RR per name </li></ul></ul></ul><ul><ul><ul><li>one RRSIG RR per RRset </li></ul></ul></ul><ul><ul><li>Overall: x5-10 zone growth AND response size growth </li></ul></ul><ul><li>Extra management </li></ul><ul><ul><li>More data passed between children and parents </li></ul></ul><ul><ul><li>Preconfiguration of trusted keys </li></ul></ul><ul><ul><li>Regularly resigning the zone </li></ul></ul><ul><ul><li>Key management </li></ul></ul>
  18. 18. Hurdles to DNSSEC Utility <ul><li>Scaling issues keep large zones (TLDs) from signing </li></ul><ul><li>Political issues keep the root from signing </li></ul><ul><ul><li>No consensus on who should hold the key(s) </li></ul></ul><ul><li>Leaf zones have few hurdles to signing </li></ul><ul><ul><li>Only useful if resolvers preconfigure keys for each of those zones </li></ul></ul><ul><ul><ul><li>Not as bad as NxN shared secret distribution </li></ul></ul></ul><ul><ul><ul><li>Still too much to maintain </li></ul></ul></ul>
  19. 19. Problem Statement <ul><li>Provide a mechanism for resolvers to validate signed zones without </li></ul><ul><ul><li>1) Maintaining separate trusted keys for each zone </li></ul></ul><ul><ul><li>2) Requiring the cooperation of those zones' ancestors </li></ul></ul>
  20. 20. Design Constraints <ul><li>Deployable! </li></ul><ul><li>Simple code </li></ul><ul><li>Scalable </li></ul><ul><ul><li>Cost directly proportional to number of clients </li></ul></ul><ul><ul><li>Cost directly proportional to number of secured zones </li></ul></ul><ul><ul><li>Able to distribute load </li></ul></ul><ul><li>Safe </li></ul><ul><ul><li>Cause no harm to non-participants (including the ancestors of participating nodes, such as the root) </li></ul></ul><ul><ul><li>No excessive load on the network </li></ul></ul><ul><ul><li>No gotchas </li></ul></ul><ul><ul><ul><li>No protocol perturbations </li></ul></ul></ul>
  21. 21. Outline <ul><li>Alternative Solutions & Related Work </li></ul><ul><ul><li>Out of band </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>Alternate tree </li></ul></ul><ul><ul><li>Overlay tree </li></ul></ul><ul><ul><li>Opt-in </li></ul></ul><ul><ul><li>FMESHD </li></ul></ul><ul><li>Trust Authorities </li></ul><ul><ul><li>Conflicts with the main tree </li></ul></ul><ul><ul><li>Resolver algorithms </li></ul></ul><ul><ul><li>Scaling enhancements </li></ul></ul><ul><ul><ul><li>Aggressive Negative Caching </li></ul></ul></ul><ul><ul><ul><li>Closest Encloser Answers </li></ul></ul></ul>
  22. 22. Out of Band <ul><li>Separate database for trust statements </li></ul><ul><li>Pros: </li></ul><ul><ul><li>Simple, understandable </li></ul></ul><ul><ul><li>No interactions with legacy DNS resolvers </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>No use of existing DNS caches </li></ul></ul><ul><ul><ul><li>Build own caching, or have difficulties scaling </li></ul></ul></ul><ul><ul><li>May not pass through firewalls as easily as DNS packets </li></ul></ul>
  23. 23. [email_address] <ul><li>Store trust statements in the zones to which they refer (ie. SSL certificates) </li></ul><ul><li>Pros: </li></ul><ul><ul><li>Scales – no longer need to run a centralized service </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>A zone can't prove that it isn't supposed to be signed </li></ul></ul><ul><ul><li>No revocation mechanism – assumes long-lived certificates (SSL) or frequent updates to the certificate </li></ul></ul><ul><li>Done before: SIG@child (RFC2535) </li></ul><ul><ul><li>Parent had records for each zone that was NOT signed </li></ul></ul><ul><ul><li>Scaling benefit lost – resolvers still hit the parent </li></ul></ul>
  24. 24. Alternate tree <ul><li>Separate root (or subtree) </li></ul><ul><ul><li>Sign the root (just not the real one) </li></ul></ul><ul><ul><li>Delegations initially the same as in the real tree </li></ul></ul><ul><ul><li>As zones want to be added, add their ancestors to the alternate tree and sign them. </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>NO resolver changes (just change root.hints) </li></ul></ul><ul><ul><li>NO protocol changes </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>History of alternate roots not getting wide adoption </li></ul></ul><ul><ul><li>Requires each ancestor zone to be available to the alternate tree operator </li></ul></ul><ul><ul><ul><li>Requires the cooperation of zone operator </li></ul></ul></ul><ul><ul><ul><li>Violates the design constraints </li></ul></ul></ul>
  25. 25. Overlay tree <ul><li>Similar to the “alternate tree”, but only include secured zones </li></ul><ul><ul><li>Resolvers first query overlay tree. If they find that the sought data doesn't exist there, look in the main tree. </li></ul></ul><ul><ul><li>No way to prove that data should not exist </li></ul></ul><ul><ul><ul><li>Allows insertion attacks </li></ul></ul></ul><ul><ul><li>Messy logic </li></ul></ul>
  26. 26. Opt-in <ul><li>VeriSign proposal to allow unsecure (no DS record) delegations to be unsigned </li></ul><ul><ul><li>Would have relieved scaling pressure on .com </li></ul></ul><ul><ul><ul><li>Zone would grow only as secure delegations added </li></ul></ul></ul><ul><ul><li>Required protocol change </li></ul></ul><ul><ul><li>Weakened security guarantees </li></ul></ul><ul><ul><li>Advantaged one player </li></ul></ul><ul><ul><li>Died in the IETF </li></ul></ul>
  27. 27. FMESHD <ul><li>DARPA project that aimed to join “islands of trust” </li></ul><ul><li>Idea: allow all zones to make trust statements about all other zones </li></ul><ul><li>Transitive trust (ie. PGP) </li></ul><ul><ul><li>Finding paths tractable in memory </li></ul></ul><ul><ul><li>Not tractable when each piece of data must be fetched in separate queries over the network </li></ul></ul><ul><ul><li>Need to bound the searching </li></ul></ul><ul><li>Never happened </li></ul>
  28. 28. Trust Authorities <ul><li>DS-like RRs (TA RRs) </li></ul><ul><li>Well-known signed zone, not the parent </li></ul><ul><li>Targets some zone </li></ul><ul><ul><li>Example: a TA for .org at the name dnssec.nl. </li></ul></ul><ul><ul><li>The TA record for riaa.org would be named riaa.dnssec.nl. </li></ul></ul><ul><li>Presence of a TA RR proves that the relevant zone should be signed </li></ul><ul><li>Absence of a TA RR (proven by an NSEC) says nothing </li></ul><ul><ul><li>Assume zones to be unsigned until proven otherwise </li></ul></ul><ul><ul><li>TA zone need not enumerate all names in its target, not even all secured ones </li></ul></ul>
  29. 29. Single-zone, Single-label TAs <ul><li>Incremental step in development </li></ul><ul><li>Marginally simpler </li></ul><ul><li>Limits utility of TAs </li></ul><ul><ul><li>DNS 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) </li></ul></ul>
  30. 30. Hierarchical Trust Authorities <ul><li>Entire DNS hierachy can be targeted </li></ul><ul><li>Allow delegations within the TA tree (using DS records) </li></ul><ul><ul><li>Share load among groups of authoritative servers </li></ul></ul><ul><ul><li>Share administrative control </li></ul></ul><ul><li>Example 1: TA for .net at ta.com </li></ul><ul><ul><li>example.ta.com. TA hash(K1) example.net DNSKEY K1 </li></ul></ul><ul><ul><li>ta.com. TA hash(K2) net DNSKEY K2 </li></ul></ul><ul><li>Example 2: TA for . at trust.com </li></ul><ul><ul><li>cnn.com.trust.com. TA hash(K3) cnn.com DNSKEY K3 </li></ul></ul><ul><li>Pressence of a TA record says that the relevant zone should be signed </li></ul>
  31. 31. Why a new RR type? <ul><li>DS and TXT already exist </li></ul><ul><li>Overloading resource records bad (RFC3445) </li></ul><ul><ul><li>May conflict with other users of those RRs </li></ul></ul><ul><li>DS RR has very special semantics </li></ul><ul><ul><li>Only record to appear ONLY at a parent </li></ul></ul><ul><ul><li>Has caused numerous problems before </li></ul></ul><ul><ul><li>Reusing it would be risky </li></ul></ul><ul><li>Using DS in hierarchical TAs to spread load </li></ul>
  32. 32. Expected problems <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>Resolver has no preconfigured keys except for ta.com. Which TA RR (which trust path) takes precedence?
  33. 33. Security Policies <ul><li>Should be up to the resolver... </li></ul><ul><li>Closest encloser trumps </li></ul><ul><li>Parent masks </li></ul><ul><li>Accept any success </li></ul><ul><li>Accept any failure </li></ul><ul><li>Accept any answer </li></ul>
  34. 34. Closest encloser trumps <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>“ The longest applicable TA record takes precedence” Validation fails.
  35. 35. Closest encloser trumps, resolver alg. <ul><li>Always have to check the TA to see if there's a closer encloser. </li></ul><ul><li>Query: www.child.example.net A </li></ul><ul><li>Ask TA: </li></ul><ul><ul><li>www.child.example.ta.com. TA ? </li></ul></ul><ul><ul><li>child.example.ta.com. TA? </li></ul></ul><ul><ul><li>example.ta.com. TA? </li></ul></ul><ul><ul><li>ta.com. TA? (would apply to .net) </li></ul></ul><ul><li>TA servers get hit (multiple times) on every (unique) query </li></ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul>
  36. 36. Parent masks <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>“ The shortest applicable TA record takes precedence” Validation fails.
  37. 37. Parent masks, resolver algorithm <ul><li>Start with the shortest label </li></ul><ul><li>Query: www.child.example.net A </li></ul><ul><li>Ask TA: </li></ul><ul><ul><li>ta.com. TA? </li></ul></ul><ul><ul><li>example.ta.com. TA? </li></ul></ul><ul><ul><li>child.example.ta.com. TA? </li></ul></ul><ul><ul><li>www.child.example.ta.com. TA ? </li></ul></ul><ul><li>TA RRs get cached </li></ul><ul><li>Worst case (nothing signed): </li></ul><ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Best case (root signed): </li></ul><ul><ul><li>Queries = #resolvers </li></ul></ul>
  38. 38. Parent masks, fallout <ul><li>There cannot be TA records for any name below another TA record </li></ul><ul><li>Can't skip around holes in the tree </li></ul><ul><li>Doesn't satisfy design goals </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>(no DS for example.net.) </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul>
  39. 39. Accept any success <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>“ Keep looking until you find a success” Validation succeeds.
  40. 40. Accept any success, resolver algorithm <ul><li>Most liberal policy </li></ul><ul><li>Test trust paths in any order </li></ul><ul><ul><li>To minimize network load, try cached TAs first </li></ul></ul><ul><li>Must exhaustively search for a good one </li></ul><ul><li>Worst case (nothing signed): </li></ul><ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Best case (root signed): </li></ul><ul><ul><li>Queries = #resolvers </li></ul></ul><ul><li>(Same as “parent masks”) </li></ul>
  41. 41. Accept any failure <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>“ If any path from any TA fails validation, give an error” Validation fails.
  42. 42. Accept any failure, resolver algorithm <ul><li>Strictest policy; results in brittleness </li></ul><ul><li>Test trust paths in any order </li></ul><ul><ul><li>To minimize network load, try cached TAs first </li></ul></ul><ul><li>Must exhaustively search for a bad one </li></ul><ul><li>Worst case (all paths validate): </li></ul><ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Best case (root TA broken): </li></ul><ul><ul><li>Queries = #resolvers </li></ul></ul><ul><li>Efficient when things are broken. </li></ul>
  43. 43. Accept any answer <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net DS K2 </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K3 </li></ul></ul><ul><ul><li>child.example.net DS K4 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>ta.com TA K1 </li></ul></ul><ul><ul><li>example.ta.com TA K3 </li></ul></ul><ul><ul><li>child.example.ta.com TA K5 </li></ul></ul>“ Try any TA (trust path) ” Unpredictable result
  44. 44. Accept any answer, resolver algorithm <ul><li>To minimize load, try cached TAs first </li></ul><ul><li>Effectively “parent masks” but not as predictable </li></ul><ul><li>Answer depends on what's cached </li></ul><ul><ul><li>Breaks DNS's “loose consistency” </li></ul></ul><ul><li>Worst case (no TA records): </li></ul><ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Best case (a TA RR for the root exists) </li></ul><ul><ul><li>Queries = #resolvers </li></ul></ul>
  45. 45. Policy comparison <ul><li>Closest encloser trumps: </li></ul><ul><ul><li>All cases: Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Parent masks: doesn't satisfy constraints </li></ul><ul><li>Accept any success: </li></ul><ul><ul><li>Worst case: Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><ul><li>Best case: Queries = #resolvers </li></ul></ul><ul><li>Accept any failure: brittle </li></ul><ul><li>Accept any answer: inconsistent </li></ul><ul><li>Queries/resolver term troubling </li></ul>
  46. 46. Aggressive negative caching <ul><li>NSEC RRs indicate that nothing exists in some span </li></ul><ul><li>a.example.net. NSEC f.example.net. ... </li></ul><ul><li>Proves that b.example.net. does not exist </li></ul><ul><li>DNS caches answers by the name asked for, NOT the name of data returned </li></ul><ul><ul><li>A subsequent query for d.example.net. would not be answered from the cache </li></ul></ul><ul><li>Could change that </li></ul><ul><ul><li>Restructure cache </li></ul></ul><ul><ul><li>Synthesize negative answers based on NSECs received in response to other queries </li></ul></ul>
  47. 47. Aggressive negative caching <ul><li>Benefit: caps the number of queries </li></ul><ul><ul><li>Once the entire NSEC chain is cached, no queries for non-existent TA records </li></ul></ul><ul><ul><li>Cap is 2*number of records </li></ul></ul><ul><ul><ul><li>One for the NSEC </li></ul></ul></ul><ul><ul><ul><li>One for the TA at that name </li></ul></ul></ul><ul><ul><li>Useful when the TA zone has very few records </li></ul></ul><ul><ul><li>Query load scales as TA records are added! </li></ul></ul>
  48. 48. Aggressive negative caching <ul><li>Problem </li></ul><ul><ul><li>What if NSECs are overreaching? </li></ul></ul><ul><ul><ul><li>The next name field is outside the zone </li></ul></ul></ul><ul><ul><ul><li>Example: www.example.net NSEC .net </li></ul></ul></ul><ul><ul><li>Resolvers should be checking that the next name is within the scope of the signing zone </li></ul></ul><ul><ul><ul><li>Otherwise, various attacks possible </li></ul></ul></ul><ul><ul><ul><ul><li>Register aaaa.com </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Generate: aaaa.com NSEC zzzz.com </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Spoof cnn.com out of existence </li></ul></ul></ul></ul><ul><ul><li>Old risk, new danger </li></ul></ul><ul><ul><ul><li>Before, an attacker would have to substitute that answer explicitly to cause misbehavior </li></ul></ul></ul><ul><ul><ul><li>Now, misconfiguration can cause misbehavior </li></ul></ul></ul>
  49. 49. Closest encloser (label stripping) <ul><li>“ Accept any succes” had worst case behavior of </li></ul><ul><ul><li>Queries = #resolvers * queries/resolver * labels/name </li></ul></ul><ul><li>Why labels/name? </li></ul><ul><li>Can't always get all TAs from one server </li></ul><ul><ul><li>Q: www.child.example.net. TA? </li></ul></ul><ul><ul><li>A: child.example.net. TA .... </li></ul></ul><ul><ul><li>example.net. TA .... (could be on another server) </li></ul></ul><ul><ul><li>net. TA .... </li></ul></ul><ul><li>And can't ask just at delegations (can't trust the unsigned delegation tree to identify delegations) </li></ul><ul><li>Slight improvement possible </li></ul>
  50. 50. Closest encloser answers <ul><li>Resolvers ask for the longest TA record </li></ul><ul><li>TA authoritative servers give back all possible TAs </li></ul><ul><ul><li>And proofs that any others don't exist </li></ul></ul><ul><li>Slight protocol perturbation </li></ul><ul><ul><li>Except for delegations, all answers have same name as the QNAME </li></ul></ul><ul><ul><li>Put the extra TA records in the “additional” section of the DNS response </li></ul></ul><ul><ul><li>More testing needed (difficult) </li></ul></ul><ul><li>Depends on security policy </li></ul><ul><ul><li>Forces choice of policy </li></ul></ul>
  51. 51. Final design <ul><li>Hierarchical TA </li></ul><ul><li>“ Accept any valid answer” resolver security policy </li></ul><ul><ul><li>Liberal policy makes for fewer failures and encourages adoption </li></ul></ul><ul><ul><li>Requires exhaustive search for TA records until one works </li></ul></ul><ul><ul><li>Performance improves as more zones are signed </li></ul></ul><ul><li>Aggressive negative caching </li></ul><ul><ul><li>Dramatically reduces TA server load in early deployment </li></ul></ul><ul><ul><li>Allows TA server load to grow slowly </li></ul></ul>
  52. 52. Performance <ul><li>Maximum query load is: </li></ul><ul><li>#resolvers * Min(queries/resolver, entries in TA) * #labels/name </li></ul><ul><li>Performance improves as zones (esp. higher level zones) are signed. Best case load: </li></ul><ul><li>#resolvers </li></ul><ul><li>The only protocol perturbation is aggressive negative caching </li></ul><ul><ul><li>No change in security properties </li></ul></ul>
  53. 53. Future work <ul><li>Closest encloser answers </li></ul><ul><ul><li>Choose a policy now (“accept any success”) </li></ul></ul><ul><li>Multiple TAs and complex security policies </li></ul><ul><ul><li>Thresholds (3 TAs configured; if one fails, the other two must succeed to result in a validation) </li></ul></ul><ul><ul><li>Augment/check the main delegation tree </li></ul></ul>
  54. 54. Deployment <ul><li>Strong consensus that some form of bootstrapping is needed for DNSSEC </li></ul><ul><ul><li>Opt-in seems to be dead </li></ul></ul><ul><ul><li>Root and TLDs are unlikely to be signed soon </li></ul></ul><ul><li>Infrastructure name server operators and resolver implementers interested in this design </li></ul>
  55. 55. Acknowledgements <ul><li>Paul Vixie </li></ul><ul><li>Suzanne Woolf </li></ul><ul><li>Johan Ihren </li></ul><ul><li>Bill Manning </li></ul><ul><li>Rob Austein </li></ul><ul><li>Mark Andrews </li></ul>
  56. 56. Lessons Learned <ul><li>Difficult to retrofit security onto something as widely deployed as DNS. Too much heterogeneity. </li></ul><ul><li>Enforcing (checking) security is about rejecting states. Security introduces brittleness. </li></ul><ul><li>DNSSEC is useless unless you create an expectation that data will be secured. Otherwise, you're subject to degradation attacks </li></ul><ul><li>Policy can drive algorithm choice, which can drive protocol design </li></ul><ul><li>Security is not survivability </li></ul>
  57. 57. The End <ul><li>Questions? </li></ul>
  58. 58. Another scenario <ul><li>Normal delegation chain </li></ul><ul><li>net.: </li></ul><ul><ul><li>net DNSKEY K1 </li></ul></ul><ul><ul><li>example.net NS (no DS) </li></ul></ul><ul><li>example.net.: </li></ul><ul><ul><li>example.net DNSKEY K2 </li></ul></ul><ul><ul><li>child.example.net DS K3 </li></ul></ul><ul><li>child.example.net: </li></ul><ul><ul><li>child.example.net DNSKEY K3 </li></ul></ul><ul><ul><li>a.b.child.example.net DS K4 </li></ul></ul><ul><li>Trust Authority ta.com for .net: </li></ul><ul><li>ta.com: </li></ul><ul><ul><li>example.ta.com TA K5 </li></ul></ul><ul><ul><li>b.child.example.ta.com TA K6 </li></ul></ul>TA says there's a b.child..., but the delegation tree doesn't!
  59. 59. DS Lameness Bug (Aug 2002) <ul><li>DS was the first RR to appear only at the parent </li></ul><ul><ul><li>Before, NS was the only RR to appear on the parent's side of a zone cut </li></ul></ul><ul><ul><li>The child had an NS RRset, too </li></ul></ul><ul><ul><li>The child could answer any question that ended with it's name </li></ul></ul><ul><ul><ul><li>Answer, NXDOMAIN, or referral </li></ul></ul></ul><ul><li>How does the child answer a query for DS? </li></ul><ul><ul><li>Referral to root </li></ul></ul><ul><ul><li>Older (non-DS-aware) resolvers said servers doing that were “lame” </li></ul></ul><ul><ul><ul><li>Quit talking to those servers </li></ul></ul></ul><ul><ul><ul><li>Zone fell off the net </li></ul></ul></ul><ul><li>Answer </li></ul><ul><ul><li>Change the response to something non-fatal (a “transient” error) </li></ul></ul>
  60. 60. DS Grandparent Problem (Oct 2002) <ul><li>Server 1 authoritative for: </li></ul><ul><ul><li>. (the root) </li></ul></ul><ul><ul><li>root-servers.net. </li></ul></ul><ul><li>Server 2 authoritative for: </li></ul><ul><ul><li>net. </li></ul></ul><ul><li>Query: </li></ul><ul><ul><li>root-servers.net. DS? (stored in net., at server two) </li></ul></ul><ul><li>Client 1, modern DS-aware code: </li></ul><ul><ul><li>Directs the query to the root (server1) </li></ul></ul><ul><ul><li>Needs a referral to net. (server2) </li></ul></ul><ul><li>Client 2, legacy code: </li></ul><ul><ul><li>Having previously done a lookup for a.root-servers.net's A record, has cached the root-servers.net NS. </li></ul></ul><ul><ul><li>Directs the query to root-servers.net. (server1) </li></ul></ul><ul><ul><li>If it gets a referral, triggers the lameness bug </li></ul></ul>
  61. 61. DS Grandparent Problem <ul><li>Incompatible needs: </li></ul><ul><ul><li>Client 1, modern: </li></ul></ul><ul><ul><ul><li>If it gets an error (instead of a referral) how does it find .net? </li></ul></ul></ul><ul><ul><li>Client 2, legacy code: </li></ul></ul><ul><ul><ul><li>If it gets a referral, triggers the lameness bug </li></ul></ul></ul><ul><li>Answer: </li></ul><ul><ul><li>Legacy code can't be changed: give the error </li></ul></ul><ul><ul><li>Find another way for the modern code to find the DS </li></ul></ul><ul><ul><li>DS is in root-servers.net.'s parent, but what's the parent? </li></ul></ul>
  62. 62. DS Grandparent Problem <ul><li>Delegations can be multi-label </li></ul><ul><ul><li>Can't just strip one label from the QNAME to find the parent </li></ul></ul><ul><ul><li>New algorithm: keep stripping labels until you find the parent </li></ul></ul>
  63. 63. NSEC Problem (Jakob's bug, Jan 2003) <ul><li>In RFC2535, NXT (the predecessor of NSEC) was only returned as part of a negative answer </li></ul><ul><li>With DS, NXT is returned on any unsecure referral (to prove that there's no DS) </li></ul><ul><li>Some code saw any NXT, assumed it meant the name didn't exist, and quit </li></ul><ul><li>Answer: change the typecodes (RFC3755) </li></ul><ul><ul><li>NXT-->NSEC </li></ul></ul><ul><ul><li>SIG-->RRSIG </li></ul></ul><ul><ul><li>KEY-->DNSKEY </li></ul></ul>
  64. 64. Degradation Attack (May 2003?) <ul><li>Safety property: properly signing a zone should not cause a zone to fall off the network </li></ul><ul><li>DNSSEC allows multiple public-key crypto algorithms </li></ul><ul><ul><li>Experimental/private algorithms </li></ul></ul><ul><ul><li>Resolvers might not support them all </li></ul></ul><ul><li>In RFC2535, each RRset had to have a SIG, made by ANY of the zone's DNSKEYs </li></ul><ul><li>If the only SIG on an RRset is from an unsupported algorithm, can't throw a hard error </li></ul><ul><ul><li>Would violate the safety property </li></ul></ul>
  65. 65. Degradation Attack <ul><li>Attack: </li></ul><ul><ul><li>substitute bogus data </li></ul></ul><ul><ul><li>and a broken RRSIG made by some obscure algorithm </li></ul></ul><ul><li>Resolver can't give a hard error </li></ul><ul><li>Prevention: never include an DNSKEY of an obscure algorithm in the DNSKEYset </li></ul><ul><ul><li>Prevents experimentation with new algorithms </li></ul></ul><ul><ul><li>Prevents replacement of algorithms if one is compromised </li></ul></ul>
  66. 66. Degradation Attack <ul><li>Answer: </li></ul><ul><ul><li>Change the expectation </li></ul></ul><ul><ul><li>Rather than: each RRset must be signed by ANY of the DNSKEYs </li></ul></ul><ul><ul><li>Use: each RRset must be signed by at least one DNSKEY of EACH algorithm in the DNSKEYset </li></ul></ul><ul><ul><li>Similar rules for DS/DNSKEY </li></ul></ul>
  67. 67. INI Powerpoint Layout <ul><li>This is the recommended layout for INI Presentations. </li></ul><ul><li>TEXT </li></ul><ul><ul><li>The chosen font is Arial . Align all text to the left. </li></ul></ul><ul><ul><li>FONT SIZES </li></ul></ul><ul><ul><ul><li>16 or 18 for body text- navy blue </li></ul></ul></ul><ul><ul><ul><li>24 or 20 Bold for sub-heads- navy blue </li></ul></ul></ul><ul><ul><ul><li>32 bold for main titles- solid white on the gray bar </li></ul></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>COLORS </li></ul><ul><ul><li>Slide Titles use solid White. Use Navy Blue for all other text. </li></ul></ul><ul><ul><li>Bullets and top banner uses a 40% Gray. </li></ul></ul><ul><ul><li>Here are some recommended highlight colors. Use as needed: </li></ul></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×