[dnssec-deployment] meeting announcement: 23 June 2004
Olaf M. Kolkman
olaf at ripe.net
Mon Jun 28 11:08:17 EDT 2004
Just to have something more tangible (and because of moral obligation)
I've tried to document my interpretation of M-N
Short description of M - N
In the M - N scheme a 'daemon' tracks changes to the DNSKEY
M treshold verification.
Whenever the DNSKEY RRset changes the signatures over the DNSKEY RRset
are validated against the existing trust anchors where by a minimum of
"M" signatures will need to verify against the current set of trust
anchors.(in addition to the standard requirement that all keys in the
keyset are self-signed).
N threshold substitution
If the verification is successful all the DNSKEYs with the SEP keys
are extracted from the DNSKEY RRset. If the set difference between the
set of extracted SEP keys and the trust anchors for that zone is
smaller than "N" the trustanchor is replaced with the extracted SEP
If the amount of signatures does not meet the "M" criterium or there
are more than "N" keys that have changed the trust-anchors are not
touche; its time for human intervention.
There is a second concept that can be attached to (or even replace)
this scheme. That is the concept of priming keys. The public part of
the priming key keypair is distributed exclusively out of band while
the signature made with the private part of the priming key keypair is
used to generate signatures over the key RR set.
The priming keys are only used when configuring trust anchors. The DNS is used
to query for a DNSKEY set. The primingkey is used for validation and if the
validation succeeds the SEP keys are extracted from the keyset to be used
as trust anchors.
The time a a priming key is used for signing the keyset is
approximately an order of magnitude larger than the time a KSK is used
to sign the keyset (you could call it an "uber" KSK).
The priming keys can be published 'in advance', e.g. in the form of
One of the stronger arguments for using priming keys is that one
could wrap the priming public keys in X.509 certificates, that would
provide key revocation functionality and 3rd party signing.
The private key material of the priming key will need to be
accessible to sign new keysets.
I have published a prototype on www.kolkman.org/dnssec/ this includes
both code for the priming key and the M-N rollover. Read the
README and check the Test Setup directory in which the rollover and
the priming are completely automated. Please do not widely distribute this
code. I don't feel it is quite ready yet.
The M-N and the Priming Key ideas are not mine. Ihren and Manning take
the credit. I take the blame for lousy explanation and/or lousy
> a. Is it a protocol change?
> This answers the in-band versus out-of-band issue.
Both M-N and priming keys can be used within the boundaries of DNSSEC
bis. In both the M-N and Priming keys scheme the client will
implicitly assume certain operational behaviour such as how often will
a query to the keyset need to be done in order to pick up a change
(daily, weekly monthly?).
> b. Is it permanent?
> This answers the "do we need to get it right the first time" issue.
> c. Applicable to the root or other trust anchors?
> Roll-over is important throughout the DNS hierarchy and a more
> broadly applicable mechanism would be preferred.
Can be used over multiple trust anchors. There will always be a need
for the initial configuration of trust-anchors in the M-N scheme. The
priming key method can be used for that but a secured website
containing a list of trust anchors would work as well.
> d. Impact of non-attention?
> This answers the "is it automated or manual" issue. We
> recognize that people will simply install "whatever" and expect
> it to work.
It supposed to work without attention, the M-N mechanism has the hooks
to warn the user that errors have occurred and that out of band
reconfiguration is needed.
When using the Priming keys failure to keep the 'priming-anchors' up
to date would result in not being able to validate the new keyset.
> e. How to recover?
> This answers the "what to do when the system (particularly the
> automated parts) fails" issue, and we know it will fail for
> reasons we can not even imagine right now.
M out of N: Reconfigure the trust-anchors out of band.
Something that occurred to me.
It may be a good idea to put a "expiration date" on the trust-anchors
and let implementations fall back to "unsecured" DNS (or raise hell
according to local policy) whenever the expiration date on the
trust-anchors passed. This is IMHO very simple to implement and
provides a good way to prevent people shooting themselves in the foot.
There may even be a way (e.g. through the signature expiration of the
sig made using a priming key) to communicate the expiration date of
(Actually I think this _is_ a good idea and I hope it can still be
configured into bind. Something like
"." <alg> <keyid> <date>;
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
More information about the Dnssec-deployment