[Opendnssec-develop] Review requirements

[Stephen.Morris at nominet.org.uk]

Jakob Schlyter <jakob at kirei.se> wrote on 12/05/2009 22:11:07:

> > 2. I see in 2.4.3: "It MUST be possible to manually roll the KSK for 
> > a zone."
> > I don't know how far this goes, but does that mean that there should 
> > be a simple command or button to do an emergency key rollover ?
> 
> yes.
> 
> > I think in case of a key compromise, I would like to have a simple 
> > button like that, so all other integrity checks are done 
> > automatically. Not only that I can manually generate a key, but all 
> > other keys and timers should be recalculated so that operation goes 
> > back to normal. An emergency key rollover without thinking what else 
> > needs to be done.
> 
> yes.

Just to amplify this, although the exact way you will tell the system to 
perform an emergency rollover still has to be defined, the operation 
itself is quite simple: the retirement date of the active key is set to 
the current time and a normal rollover is initiated.



> > 3. 2.4.3: "6. The production of a new KSK for a zone MAY be notified 
> > to the operator if such notifications are enabled."
> > I would like to have a configurable notification option as well 
> > where I am warned in advance that a KSK rollover will be necessary 
> > in a specific timeframe.
> 
> seems like reasonable thing that one would like to ask the KASP 
enforcer.

I agree.



> > So f.e a notification that I need to generate new keys in the coming 
> > month. In cases of some higher security, f.e. when manual 
> > intervention for KSK generation is needed (offline signing).
> > Do we still find that applicable ? Is there still an opinion that 
> > ZSK rollovers are handled by the HSM/signer, but KSK rollovers can/ 
> > should be done offline ?
> 
> currently, all key handling is done online. we've had discussion 
> regarding operations that involves carbon life forms as well, but 
> nothing is currently implemented as far as I know.

This sounds like something we need to specify more closely.



> > 4. Don't know if this is a nice to have or a requirement: I would 
> > like to have some state reporting to see how my signing is 
> > progressing.
> > A sort of oversight of all the zones with the versions of KSK and 
> > ZSK's used or ready to be used to monitor the signing process.
> 
> yes that would be nice. please send code :-)  (sorry, I had to say that)

I'm not sure about the a status report when the signer is in operation 
(Jelte, how feasible is this?), but a status report showing all zones, 
what keys are in the zone, and when the keys are due for replacement 
should be obtainable from the KASP database.

In fact, looking through the requirements document I realise that it says 
nothing about reporting current status.  It mentions a GUI (to be defined) 
for configuration and use of syslog to report what has happened, but 
nothing to report what _is_ happening - status of signer, KASP, keys etc. 
What are people's thoughts here?



> > 5. Parent interaction
> > How configurable will the KSK notifications be ? I'm thinking of 
> > parsing notifications directly to my parent. You'll have questions 
> > like do I need the DNSKEy, should I calculate the DS, can I follow 
> > the update process at the parent, in other words, what information 
> > and format do I need for KSK notification ?
> 
> as far as I know, we have not discussed parent-child interaction yet.

I think we need to discuss this.



> > 6. There is a requirement for multiple HSM's to facilitate migration 
> > to new HSM's. I think another use case is that there are more zones/ 
> > keys than fit in a single HSM, so you'll need extra HSM's to expand 
> > capacity. That use case should be provided too. I think it says that 
> > correctly in the requirements, but I want to make sure.
> 
> we have a capacity value for each HSM so that should be possible.

I think that the note on requirement 2.4.2.3 should be moved to 
requirement 2.4.2.4.a to make this clearer.



> > 7. Integrity checking
> > We are used to do integrity checking before a zone is published. 
> > However, we can do a lot of integrity checking because we generate a 
> > complete new build of a zone. So we can compare the old zone with 
> > the new one and see if there is not a major change. I have 2 
> > questions: Will integrity checking be done only on the DNSSEC data, 
> > or also on other parameters (What happens f.e. if the outputted zone 
> > is DNSSEC correct but has 90% less data). Or in other words do I 
> > still need integrity checking of the zone before and after I submit 
> > it to the signer.
> 
> IMHO, the KASP auditor should only audit what the KASP states - so 
> garbage in, garbage out.

The requirements for the KASP auditor includes two requirements to check 
non-DNSSEC data as well:

 1. All non-DNSSEC data (i.e. all RRs except NSEC, NSEC3, NSEC3PARAM, 
DNSKEY and RRSIG) in the input zone must be identical to that in the 
output zone. The only exception is SOA, where it is permissible for the 
serial number to differ.
 2. The KA may retain the SOA serial number for a zone between runs and 
warn if the zone serial number has decreased. 

(KA = KASP Auditor)


 
> > And the second question is how configurable will this be ? I can 
> > imagine there are zone specific checks you want performed (this 
> > record should be in there). Or is this out of scope ?
> 
> I think this is out of scope.

I agree that adding specific checks to the contents of the zone is out of 
scope of the project, although allowing some way for a user-specified 
checking program to gain control at some point may not be.  However, being 
able to configure the supplied checks is certainly in scope.  The 
requirements suggest that the auditor be configured to run on the entire 
zone or just a sample of the zone.  But should we require each of the 
checks (non-DNSSEC data, DNSKEY, NSEC etc.) to be configurable, e.g. give 
options to check the entire zone, not run the check, or check only a 
sample?


 
> > 8. Performance
> > I think this does indeed need more specification, and I think the 
> > current requirement is quite low.
> > I don't know how this will impact the one large zone versus lot's of 
> > small zones, or how that performance changes when increments are 
> > signed later, or do we think about that in a next stage ?
> 
> parts of the performance is depending on what HSM is used, but also 
> how scheduling is done. I think we need to revisit this after the 
> first version is released.
> 
> > Shouldn't we have similar performance figures for integrity 
> > checking ? (The more you check, the longer it takes).
> 
> yes, probably.

... although if you allow the checking of a sample of a zone, you can tune 
the size of the sample to fit your checking window.



I think that there are a number of issues that would we worth further 
discussion; could we add them to the agenda for the next teleconference? I 
don't think that anything here should delay the alpha release, but there 
are a number of things that we should perhaps consider adding to the beta 
version.

Stephen