DNSKEY rollover and priming

1. DNSKEY rollover and priming Johan Ihrén Autonomica johani@autonomica.se

2. Caveat • We were in a bit of a hurry to get this draft in before the deadline • we know there are bugs in there, which we’ll address in the next revision • but because this is a crucial area with other proposals (f.i. the msj draft) we felt it was important to get this documented so that the different proposals can be compared side to side johani@autonomica.se

3. Problem area • Validators will have to configure and maintain trust anchors (“TAs”) • At least one, but probably more to many more trust anchors will need to be maintained • 10+? 100+? 1000+? • At the “zone owner” side the policies and procedures for key rollovers will be different from zone to zone johani@autonomica.se

4. The Problems • How does a validator bootstrap the trust anchors needed for validation? • is it possible to do that based on existing trust relations? • How does a validator maintain its trust anchors once configured? • i.e. how to track all rollovers for all configured TAs (may be a lot of work) johani@autonomica.se

5. Automated RolloverImplicit Requirements • No protocol changes • Keeping Minimum State • No specific timing issues • DNS only johani@autonomica.se

6. Our proposal: M-of-N rollover validation • Given a security apex “.YY” where there are several keys, “N keys”. • Furthermore the set of keys is signed by each key, i.e. there are N signatures over the keys. • Then automatic tracking of key rollovers becomes possible if the resolver adopts the local policy: • Best of all is that this can be achieved entirely outside the actual resolver, since this only affects the store of trusted keys, not the actual behaviour of the resolver. “If the set of keys changes, but the new set is signed by at least M keys that I already trust then I will accept every key in the new set as a trusted-key” johani@autonomica.se

7. The Threshold Concept • Use existing trust anchors and a “treshold validation mechanism” to maintain the trust anchors. • Algorithm • M of the existing trust anchors need to validate the new key set • Not more than N SEP keys differ johani@autonomica.se

8. Missing parts in the draft • The draft has not considered a class of replay attacks • this can be fixed by maintaining state i.e. maintaining a log of previously used trust anchors • Thorough analysis of the “client states” • what happens if the zone owner does not do what it MUST do, etc johani@autonomica.se

9. BootstrappingImplicit Requirements • …. • Not necessarily in band • Possibility to use out-of-DNS technology • Not used to maintain the trust anchor set • Note the problem of priming a device that sits in a shrink-wrapped box for a long time before being brought into use • with automated (frequent) rollovers any TAs it had will be stale (and therefore dangerous) johani@autonomica.se

10. The Priming Concept • Sign the RRKEY set with a private key which does not have its public key in DNS • the “priming key” • The Priming Key is conceptually an über key signing key • Distribute the priming key public key using an existing trust relation johani@autonomica.se

11. A distribution methodNice things to have • Generally available • Existing trust relation • Public key revocation • Did somebody mention X509? johani@autonomica.se

12. Conclusions? johani@autonomica.se

13. Thanks! johani@autonomica.se

14. An attempt at comparision • This is a barebones comparision of the main differences between our proposal and the msj proposal. johani@autonomica.se

15. “Trust Anchors” • msj: several individual TAs • need explicit revoke to protect against single key compromise • “traditional” semantics for trust (any one key is fine) • johani: one “aggregated” TA (an aggregate of several keys) • no need for explicit revoke • more complex semantics for “when to trust” (an update) - “M of N” johani@autonomica.se

16. “Rollover semantics” johani@autonomica.se

17. “Priming” • I.e. how to get started. • msj: no support, different problem • johani: long lived “priming keys” used to bootstrap the rollover state machine • similar to the process of priming the NS RRset for “.” from the hints file johani@autonomica.se

18. “Recovery” • This is the action needed when the state machine has failed for whatever reason • one example may be that a validating resolver has been off the net for long enough to not see a series of rollover events and is “too far behind” • msj: no support? • johani: just restart with the same priming keys used last time johani@autonomica.se