[dnssec-deployment] meeting announcement: 23 June 2004

Olaf M. Kolkman olaf at ripe.net
Mon Jun 28 11:08:17 EDT 2004


Hi all...

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
 RRset. 

 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
 keys.

 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.


Priming Keys.

 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
 OS patches. 

 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.


Implementation.

 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
implementation. 


> 
>      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.



Finally.

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
trust anchors.

(Actually I think this _is_ a good idea and I hope it can still be 
configured into bind. Something like

	     
trusted-keys-expiration {
			"."  <alg> <keyid> <date>;
			}

)


-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC




More information about the Dnssec-deployment mailing list