OpenDNSSEC > Meetings > Minutes > 2009-05-18
Present, in order of appearance: Stephen, Rick (taking notes), Jakob, Sion, Rickard, Patrik, John, Jelte, Matthijs.
libhsm
Jelte is working on libhsm. Most will be done this week, the rest next week. Then he will need one more week to polish the code.
API change proposals will be discussed with Jakob.
Sion needs key generation most of all, Jelte will start with that.
Code reviewing
Sion: Will libhsm be reviewed later? Rickard acknowledges this intention.
John looked at the signer engine, a few common todo:s rolled out of it. The signing tool had only minor issues.
Matthijs looked at libksm and enforcer. Reviews have been sent, basically README issues on parameter handling, only minor things. Sean has not yet processed the enforcer:s feedback, but libhsm is done.
Rickard lookd at libksm and enforcer. Code looks good, comments sent to Sion. We discussed what to do when memory allocation failed, and agreed that it was so serious that exiting with a remark to the logs would be fine.
Jan (external reviewer) has not reported, Rickard sent materials to him by end of April.
Sion wonders if we wouldn:t need a review on the overall structure, and we agree; Rickard will take note of it in our schedule.
Jelte proposes to do future reviews on changes, rather than on the whole thing from scratch. That means we need to tag the code as it stands after processing review comments. Rickard will arrange this.
Discussion about each component
Sion has mostly processed reviewer:s comments. Libksm takes a few more days, and so does the enforcer.
John proposes to arrange some standard test files to test against, and Sion agrees that a test suite would be good to write.
Jelte has not done much on the signer engine, it is still running.
Jelte needs to finish libhsm and then use it in the signer engine.
Rickard is making the softhsm more robust, and has a RC2 version coming up.
Discussion about requirements (from the mailing list)
How should an operator tell OpenDNSSEC to do an emergency key rollover?
The database has a flag that simply needs to be set. In our alpha release, we agre to use this to initiate standard key rollover. In full releases, we agree that a "management library" is the best option, with a trivial commandline frontend. This will simplify future (3rd party?) roll-out of graphical management tools.
Do we want to get warned in advance that a KSK rollover will be necessary in a specific timeframe?
Yes, this is useful with holiday planning in mind. It is easy to do through low-priority logging.
Do we want to be able to do the KSK rollover offline?
This is useful, but we decide to defer offline things to version 2.
Would we like to know the current status of the components, HSM:s, a zone and its keys (signing progress, ...)?
Yes, we like that. This too is best added to a "management library" with a trivial commandline front-end.
How should OpenDNSSEC ease the child-parent interaction when distributing the public key?
This is currently not done. DS and/or DNSKEY can be reported through the same logging mechanisms as the early warnings for key rollover. Ultimately, that is in version 2, we would like to poll the parent to automatically detect that it has moved on to the new key. This discussion is further deferred to the list.
Can the key usage of a zone expand to multiple HSM:s?
Stephen would like to be able to move to another HSM if one is full. He envisions a pool of HSMs, in each of which new keys can be generated. If one is full, OpenDNSSEC would move on to try on the next one. All this is agreed upon as being advanced, and material for version 2.
Do we have performance requirements for other than a single large zone?
Requirements are kindly requested. These ought to be more specific than "a large number of small zones". Rick will rack up some figures through SurfNet?.
Should the sep bit being used in a way consistent with RFC5011 or in a way consistent with the policy?
RFC 5011 is not an ideal RFC, and supporting it blindly is agreed not to be a good idea. We therefore make RFC 5011 support an option. This means that we will adapt the respective remarks about RFC support in our claims of the OpenDNSSEC product.
Should we support RSA/MD5?
No.
Should the signer be able to change the TTL, minimum and serial numbers for the SOA to be able to match the policy?
Yes. Stephen adds that we should be explicit, raising a warning flag of some kind.
Should the user be able to choose the format?
This refers to the serial format. This is already an option, so Yes.
What serial number formats should be considered?
We currently support serial, datetime, datecounter. Ideally, we would like to support unchanged serial numbers as well, but this is not feasible and we cannot currently see how we could.
Should we worry about leap-seconds?
No. We leave that to Unix: timers.
Is the year 2038 problem too far away to worry about now?
This is not a problem. If zones are resigned at the recommended pace, we will stay far away from any such trouble.
KASP Auditor
Do we want to do integrity checking of more than the DNSSEC data?
Yes. At least consistency between signed and unsigned records.
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?
Yes. If there are large numbers of domains to be verified, sampling may be a very practical option.
Should it be possible to ignore warnings about NSEC/NSEC3 records when in NSEC3/NSEC mode during a transition?
Yes.
Should we develop the KA in Ruby using the DNSRuby library?
Yes. A fresh man at Nominet, who can look at the code from a new perspective, can do just that.
System install / users guide
Patrik has postponed this a bit, as he wants to see the system running first.
Jakob reports that the code builds and configures well, and seems to work well together.
HSM compliancy tool
Rick reports that this work is in progress, most tests have been implemented. The initial tests will be against the softhsm, the code of which Rick will not look into; instead, Rick and Rickard will find out who is deviating from the PKCS #11 standard in case of discrepancies. Concurrency is not tested, as only very complex models could do this representatively, and that would basically mean rebuilding OpenDNSSEC in a little tool.
Jakob suggests to incorporate libhsm in the tests, and Rick will look into that. Jakob also offers to set Rick up with a true HSM.
New HSM:s
We do a small survey of possible HSM models on the market. We come up with
* IBM 4046 crypto-coprocessors * SafeNet? is interested in DNSSEC as an application, Rick and Jakob will exchange contacts at SafeNet?. * HP is in contact with John. * nCipher has networked HSM:s. * Are there any tokens with support for many keys? We can:t think of any.
Platform support
Everybody is requested to fill in the online platform support page.
System testing
This is postponed until the requirements are finished.
Roadmap
This will be removed from the wiki as it spreads more confusion than clarity.
Presentation at RIPE
Went fairly good. France and Finnish TLDs showed an interest in OpenDNSSEC.
Next meeting
Complex, so we will Doodle on it.
If we decide to switch to drums for communication, we will be informed in enough time for everyone to get a drumkit.
Other questions
Jelte is asked to notify the list if libhsm is usable.
