Dnskey rollover and priming
1 / 18

DNSKEY rollover and priming - PowerPoint PPT Presentation

  • Uploaded on

DNSKEY rollover and priming. Johan Ihrén Autonomica. [email protected] 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' DNSKEY rollover and priming' - malia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • 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

[email protected]

Problem area
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

[email protected]

The problems
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)

[email protected]

Automated rollover implicit requirements
Automated RolloverImplicit Requirements

  • No protocol changes

  • Keeping Minimum State

  • No specific timing issues

  • DNS only

[email protected]

Our proposal m of n rollover validation
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”

[email protected]

The threshold concept
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

[email protected]

Missing parts in the draft
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

[email protected]

Bootstrapping implicit requirements
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)

[email protected]

The priming concept
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

[email protected]

A distribution method nice things to have
A distribution methodNice things to have

  • Generally available

  • Existing trust relation

  • Public key revocation

  • Did somebody mention X509?

[email protected]

An attempt at comparision
An attempt at comparision

  • This is a barebones comparision of the main differences between our proposal and the msj proposal.

[email protected]

Trust anchors
“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”

[email protected]


  • 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

[email protected]


  • 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

[email protected]