From sara at sinodun.com Tue Jul 1 13:58:53 2014 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 1 Jul 2014 14:58:53 +0100 Subject: Fwd: [Opendnssec-develop] Team meeting - Tuesday 1 July @ 14:00 CEST References: Message-ID: <22CC3813-47A6-4DBE-BF76-836EA5D22F86@sinodun.com> Hi All, The minutes from the meeting today are available for review: https://wiki.opendnssec.org/display/OpenDNSSEC/2014-07-01+Minutes Sara. Begin forwarded message: > From: Sara Dickinson > Subject: [Opendnssec-develop] RE: Team meeting - Tuesday 1 July @ 14:00 CEST > Date: 30 June 2014 12:45:13 BST > To: Opd Dev > > Hi All, > > We have a team meeting scheduled for tomorrow: > > Date: Tuesday 1 July 2014 > Time: 14:00-15:00 CEST, 13:00-14:00 BST, 20:00-21:00 CST, 12:00-13:00 UTC > Method: Teamspeak (https://wiki.opendnssec.org/display/OpenDNSSEC/Conference+call+details) > Agenda: https://wiki.opendnssec.org/display/OpenDNSSEC/2014-07-01+Agenda > > Sara. > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From matthijs at nlnetlabs.nl Fri Jul 4 11:07:08 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Fri, 04 Jul 2014 13:07:08 +0200 Subject: [Opendnssec-develop] kasp draft Message-ID: <53B68ADC.8080501@nlnetlabs.nl> Hi, Jerry and I thought it would be a good idea to standardize key and signing policies (format and behavior), now that more people announced that they have implementing key policies on their road map. We have published a draft and intend to get it adopted by the dnsop wg: http://datatracker.ietf.org/doc/draft-mekking-dnsop-kasp/ We would like to hear your opinions about this and get your feedback. Best regards, Matthijs From yuri at nlnetlabs.nl Fri Jul 4 13:15:24 2014 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Fri, 04 Jul 2014 15:15:24 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53B68ADC.8080501@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> Message-ID: <53B6A8EC.1040800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > We would like to hear your opinions about this and get your > feedback. 1) 2.1.1.2 (...) The choice and case modeling types are not included in the actual data tree. In the case that NSEC is used, the XML example would be: I don't understand what 'choice and case modeling types' are. 2) 2.1.1.4. Zone 3. Serial - The format of the serial number in the signed zone. This is one of: "counter", datecounter, unixtime, keep. Perhaps Serial should not be defined as a string but rather a type that has one of the above values. 3) 2.1.1.4 It is unclear which values in the Zone>SOA container are optional. 4) If everything in the parent container is optional, why MUST we have a parent container? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlO2qOgACgkQI3PTR4mhavg7EQCgqYk5YYbEvGdN02YtFMt+VZ9m FcEAn1bunKSrHO50rtWEEWx2WBkH3aGW =/So3 -----END PGP SIGNATURE----- From matthijs at nlnetlabs.nl Fri Jul 4 13:23:42 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Fri, 04 Jul 2014 15:23:42 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53B6A8EC.1040800@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> Message-ID: <53B6AADE.9060804@nlnetlabs.nl> On 07/04/2014 03:15 PM, Yuri Schaeffer wrote: >> We would like to hear your opinions about this and get your >> feedback. > > 1) 2.1.1.2 > (...) > The choice and case modeling types are not included in the actual > data tree. In the case that NSEC is used, the XML example would be: > > > > > > I don't understand what 'choice and case modeling types' are. Its YANG language (RFC 6020). Basically you specify in your model that you have a choice: Either the schema contains or the schema contains . You cannot have both and at the same time. A case modeling type is a choice option so to say. > 2) 2.1.1.4. Zone > > 3. Serial - The format of the serial number in the signed zone. > This is one of: "counter", datecounter, unixtime, keep. > > Perhaps Serial should not be defined as a string but rather a type > that has one of the above values. I was thinking of that too. I'll add that as an issue to be resolved. > 3) 2.1.1.4 > It is unclear which values in the Zone>SOA container are optional. Ok, I'll take a look. > 4) If everything in the parent container is optional, why MUST we have > a parent container? This can probably be a MAY. We started with kasp.rnc with this document and then relaxed some rules. I created issues for these in github: https://github.com/matje/dnsop-kasp/issues. Thanks Yuri! Best regards, Matthijs > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From Roland.vanRijswijk at surfnet.nl Mon Jul 7 07:01:15 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Mon, 07 Jul 2014 09:01:15 +0200 Subject: [Opendnssec-develop] Post mortem: service disruption on wiki.opendnssec.org and issues.opendnssec.org Message-ID: <53BA45BB.8070306@surfnet.nl> Hi all, Last night, just before midnight CEST we experienced a power failure in one of our data centers; unfortunately, the second power supply on our brand new storage cluster which should have taken over also failed, causing disruption to some VMs running on our infrastructure. The server hosting the OpenDNSSEC Confluence and JIRA instances was also affected. Unfortunately, Mr. Murphy wasn't quite done with us yet, as it turned out that one of the admins had forgotten to configure Apache for auto-startup. I believe that in polite English this is called a "clusterf**k". This has now been remedied and services have been restored. The service was down between approx. 23:30h CEST and 8:50h CEST. I apologize for the inconvenience this may have caused. Best regards, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From Roland.vanRijswijk at surfnet.nl Mon Jul 7 12:10:14 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Mon, 07 Jul 2014 14:10:14 +0200 Subject: [Opendnssec-develop] Short maintenance window on Crowd at 15:00h CEST Message-ID: <53BA8E26.5060708@surfnet.nl> Dear all, At 15:00h CEST today there will be a short maintenance window on the OpenDNSSEC Crowd (single sign-on for Confluence and JIRA) server. The service will be restarted at that time and may be unavailable for up to 5 minutes. During this time, logging in to Confluence and JIRA will not be possible, but content can still be accessed. Best regards, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From Roland.vanRijswijk at surfnet.nl Mon Jul 7 14:41:22 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Mon, 07 Jul 2014 16:41:22 +0200 Subject: [Opendnssec-develop] [closed] Short maintenance window on Crowd at 15:00h CEST Message-ID: <53BAB192.5090905@surfnet.nl> Dear all, The maintenance on Crowd was performed successfully, the service is fully operational again. Cheers, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From matthijs at nlnetlabs.nl Thu Jul 10 14:31:42 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Thu, 10 Jul 2014 16:31:42 +0200 Subject: [Opendnssec-develop] Release 1.4.6 Message-ID: <53BEA3CE.3020303@nlnetlabs.nl> Hi, Now that pull 109 has been merged, I am happy with doing a release. Best regards, Matthijs From sara at sinodun.com Thu Jul 10 16:13:31 2014 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 10 Jul 2014 17:13:31 +0100 Subject: [Opendnssec-develop] Release 1.4.6 In-Reply-To: <53BEA3CE.3020303@nlnetlabs.nl> References: <53BEA3CE.3020303@nlnetlabs.nl> Message-ID: <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> On 10 Jul 2014, at 15:31, Matthijs Mekking wrote: > Hi, > > Now that pull 109 has been merged, I am happy with doing a release. > > Thanks Matthijs - yes lets go ahead with the release now. I believe we are also in a position to do a 1.3.18 release at the same time since OPENDNSSEC-632 is closed (thanks Warren). Jerry could you please create both release candidate tarballs when you have time? Thanks Sara. From jerry at opendnssec.org Fri Jul 11 06:05:23 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Fri, 11 Jul 2014 08:05:23 +0200 Subject: [Opendnssec-develop] Release 1.4.6 In-Reply-To: <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> References: <53BEA3CE.3020303@nlnetlabs.nl> <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> Message-ID: <1405058723.31661.2.camel@what> On tor, 2014-07-10 at 17:13 +0100, Sara Dickinson wrote: > I believe we are also in a position to do a 1.3.18 release at the same time since OPENDNSSEC-632 is closed (thanks Warren). > > Jerry could you please create both release candidate tarballs when you have time? 1.4 is failing on FreeBSD 10 now because of an updated SQLite, going to see that all of that is green before I go ahead with the release. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From jerry at opendnssec.org Fri Jul 11 08:49:29 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Fri, 11 Jul 2014 10:49:29 +0200 Subject: [Opendnssec-develop] Release 1.4.6 In-Reply-To: <1405058723.31661.2.camel@what> References: <53BEA3CE.3020303@nlnetlabs.nl> <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> <1405058723.31661.2.camel@what> Message-ID: <1405068569.5103.0.camel@what> On fre, 2014-07-11 at 08:05 +0200, Jerry Lundstr?m wrote: > 1.4 is failing on FreeBSD 10 now because of an updated SQLite, going to > see that all of that is green before I go ahead with the release. All issues resolved, going ahead with releases. Might take an hour or two since I need to update my release VM. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From jerry at opendnssec.org Fri Jul 11 09:43:42 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Fri, 11 Jul 2014 11:43:42 +0200 Subject: [Opendnssec-develop] Release 1.4.6 In-Reply-To: <1405068569.5103.0.camel@what> References: <53BEA3CE.3020303@nlnetlabs.nl> <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> <1405058723.31661.2.camel@what> <1405068569.5103.0.camel@what> Message-ID: <1405071822.5103.4.camel@what> 1.3.18rc1 https://dist.opendnssec.org/source/testing/opendnssec-1.3.18rc1.tar.gz https://dist.opendnssec.org/source/testing/opendnssec-1.3.18rc1.tar.gz.sig SHA1 9f7245b10af42ad973258dda9e0cdae4db418fcb SHA256 f77d155da80cbc6b6f1b05631a10d80ca43703e8151e580922ca505acbacbe4a 1.4.6rc1 https://dist.opendnssec.org/source/testing/opendnssec-1.4.6rc1.tar.gz https://dist.opendnssec.org/source/testing/opendnssec-1.4.6rc1.tar.gz.sig SHA1 987552c44af449a0c7bebfe602a60b5f30fa67b9 SHA256 2037623150d35a0881f91ec1953050d44afc502229e7a0139d4513616d269ca7 -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From sara at sinodun.com Fri Jul 11 14:36:37 2014 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 11 Jul 2014 15:36:37 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.18rc1 release candidate Message-ID: <26F54F70-3CE6-4339-AC85-2299EF5406C7@sinodun.com> All, Version 1.3.18rc1 of OpenDNSSEC is now available. This is a release candidate for testing purposes: OpenDNSSEC 1.3.18rc1 ??????????? Updates: * OPENDNSSEC-620: conf.xml: New options: for both enforcer and signer, and for the signer. * Build: Fixed various OpenBSD compatibility issues found by Patrik Lundin . * New tool: ods-getconf: to retrieve a configuration value from conf.xml given an expression. Bugfixes: * OPENDNSSEC-632: ods-ksmutil: 'zone add' command when zonelist.xml.backup can't be written zone is still added to database, solved it by checking the zonelist.xml.backup is writable before adding zones, and add error message when add zone failed. * OPENDNSSEC-624: memory leak when signer failed, solved it by add ldns_rr_free(signature) in libhsm.c * simple-dnskey-mailer.sh: Fix syntax error. (by Patrik Lundin https://github.com/eest) * libhsm: Fixed a few other memory leaks. Download: * https://dist.opendnssec.org/source/testing/opendnssec-1.3.18rc1.tar.gz * https://dist.opendnssec.org/source/testing/opendnssec-1.3.18rc1.tar.gz.sig * Checksum SHA1: 9f7245b10af42ad973258dda9e0cdae4db418fcb * Checksum SHA256: f77d155da80cbc6b6f1b05631a10d80ca43703e8151e580922ca505acbacbe4a A full OpenDNSSEC 1.3.18 release is planned for Friday 18th July //OpenDNSSEC team From sara at sinodun.com Fri Jul 11 14:36:40 2014 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 11 Jul 2014 15:36:40 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.6rc1 release candidate Message-ID: <8B903913-3025-479F-AF01-BC7259F3348B@sinodun.com> All, Version 1.4.6rc1 of OpenDNSSEC is now available. This is a release candidate for testing purposes: OpenDNSSEC 1.4.6rc1 ??????????????? Updates: * Signer Engine: Print secondary server address when logging notify reply errors. * Build: Fixed various OpenBSD compatibility issues found by Patrik Lundin . * OPENDNSSEC-621: conf.xml: New options: for both enforcer and signer, and for the signer. * New tool: ods-getconf: to retrieve a configuration value from conf.xml given an expression. Bugfixes: * OPENDNSSEC-469: ods-ksmutil: 'zone add' command when zonelist.xml.backup can't be written zone is still added to database, solved it by checking the zonelist.xml.backup is writable before adding zones, and add error message when add zone failed. * OPENDNSSEC-617: Signer Engine: Fix DNS Input Adapter to not reject zone the first time due to RFC 1982 serial arethmetic. * OPENDNSSEC-619: memory leak when signer failed, solved it by add ldns_rr_free(signature) in libhsm.c * OPENDNSSEC-627: Signer Engine: Unable to update serial after restart when the backup files has been removed. * OPENDNSSEC-628: Signer Engine: Ingored notifies log level is changed from debug to info. * OPENDNSSEC-630: Signer Engine: Fix inbound zone transfer for root zone. * libhsm: Fixed a few other memory leaks. * simple-dnskey-mailer.sh: Fix syntax error. (by Patrik Lundin https://github.com/eest) Download: * https://dist.opendnssec.org/source/testing/opendnssec-1.4.6rc1.tar.gz * https://dist.opendnssec.org/source/testing/opendnssec-1.4.6rc1.tar.gz.sig * Checksum SHA1: 987552c44af449a0c7bebfe602a60b5f30fa67b9 * Checksum SHA256: 2037623150d35a0881f91ec1953050d44afc502229e7a0139d4513616d269ca7 A full OpenDNSSEC 1.4.6 release is planned for Friday 18th July. //OpenDNSSEC team From sion at nominet.org.uk Tue Jul 15 08:52:22 2014 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 15 Jul 2014 09:52:22 +0100 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53B6AADE.9060804@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> Message-ID: <53C4EBC6.5090308@nominet.org.uk> 2.1.1. "a policy MUST have the containers Signatures, Denial, Keys, Zone and Parent." This is only true for a policy that can control a key rollover; If all I want is to describe the signing part then "Parent" becomes optional. I guess this is the same as Yuri's comment? 2.1.1.1 Jitter - I'm not sure that there is a need to define the jitter algorithm... I can have jitter that only increases signature lifetimes (i.e. r * j) and it is still just as valid. The algorithm could be given as an example. 2.1.1.2 Can Resalt be PT0S? If so what does this mean? Can SaltLength be 0? (In general by integer you mean positive integer; possibly including zero? This is all explicit in the current kasp.rnc) 2.1.1.3 Does Repository need to be mandatory? Is this only the case if the signer uses PKCS11 (I'm not sure of the answer to this; but e.g. "keys on disc" would need a path instead). Sion On 04/07/14 14:23, Matthijs Mekking wrote: > On 07/04/2014 03:15 PM, Yuri Schaeffer wrote: >>> We would like to hear your opinions about this and get your >>> feedback. >> 1) 2.1.1.2 >> (...) >> The choice and case modeling types are not included in the actual >> data tree. In the case that NSEC is used, the XML example would be: >> >> >> >> >> >> I don't understand what 'choice and case modeling types' are. > Its YANG language (RFC 6020). Basically you specify in your model that > you have a choice: Either the schema contains or the schema > contains . You cannot have both and at the same > time. A case modeling type is a choice option so to say. > > >> 2) 2.1.1.4. Zone >> >> 3. Serial - The format of the serial number in the signed zone. >> This is one of: "counter", datecounter, unixtime, keep. >> >> Perhaps Serial should not be defined as a string but rather a type >> that has one of the above values. > I was thinking of that too. I'll add that as an issue to be resolved. > > >> 3) 2.1.1.4 >> It is unclear which values in the Zone>SOA container are optional. > Ok, I'll take a look. > > >> 4) If everything in the parent container is optional, why MUST we have >> a parent container? > This can probably be a MAY. We started with kasp.rnc with this document > and then relaxed some rules. > > > I created issues for these in github: > https://github.com/matje/dnsop-kasp/issues. > > Thanks Yuri! > > Best regards, > Matthijs > >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop >> > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jerry at opendnssec.org Tue Jul 15 09:18:25 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Tue, 15 Jul 2014 11:18:25 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53C4EBC6.5090308@nominet.org.uk> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> Message-ID: <1405415905.7280.2.camel@what> On tis, 2014-07-15 at 09:52 +0100, Si?n Lloyd wrote: > 2.1.1.3 > Does Repository need to be mandatory? Is this only the case if the > signer uses PKCS11 (I'm not sure of the answer to this; but e.g. "keys > on disc" would need a path instead). Repository does not explicitly mean PKCS#11, keys needs to be stored somewhere and repository is only the name for it. It can be a keys on disc solution or PKCS#11. Maybe add some clarification on what Repository is and that it should also be configured elsewhere depending on implementation. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From Roland.vanRijswijk at surfnet.nl Fri Jul 18 15:21:00 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Fri, 18 Jul 2014 17:21:00 +0200 Subject: [Opendnssec-develop] Maintenance on Confluence, JIRA and Crowd - Monday July 21st 9:00h CEST Message-ID: <53C93B5C.3030201@surfnet.nl> Dear all, This is to inform you that next Monday, July 21st at 9:00h CEST there will be a brief maintenance window for the OpenDNSSEC Confluence, JIRA and Crowd instances that may lead to these services being unavailable for a couple of minutes in the time window between 9:00h CEST and 10:00h CEST. Best regards, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From jerry at opendnssec.org Mon Jul 21 08:57:15 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Mon, 21 Jul 2014 10:57:15 +0200 Subject: [Opendnssec-develop] Your Confluence license maintenance expires in 30 days. Contact Atlassian or remind me later. Message-ID: <1405933035.5551.1.camel@mine> Hi Roland, Our Atlassian licenses are expiring, can you look at this for all our sites? "Your Confluence license maintenance expires in 30 days. Contact Atlassian or remind me later." Cheers! -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part URL: From jerry at opendnssec.org Mon Jul 21 09:42:56 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Mon, 21 Jul 2014 11:42:56 +0200 Subject: [Opendnssec-develop] Release 1.4.6 In-Reply-To: <1405071822.5103.4.camel@what> References: <53BEA3CE.3020303@nlnetlabs.nl> <6A5EE90F-413A-4C39-8B00-6D869C696D81@sinodun.com> <1405058723.31661.2.camel@what> <1405068569.5103.0.camel@what> <1405071822.5103.4.camel@what> Message-ID: <1405935776.5551.4.camel@mine> 1.3.18 https://dist.opendnssec.org/source/opendnssec-1.3.18.tar.gz https://dist.opendnssec.org/source/opendnssec-1.3.18.tar.gz.sig SHA1 6c860096257955b3559c1d42cf59047332f3d1ee SHA256 e61d23ae0cc57b6e09d408bade6872fe5241896c61a03e8bc5ceeb65df13a676 1.4.6 https://dist.opendnssec.org/source/opendnssec-1.4.6.tar.gz https://dist.opendnssec.org/source/opendnssec-1.4.6.tar.gz.sig SHA1 2318b31546d0d4118cd03b9591ba76d259e1b0b0 SHA256 53f9c454f331822925d76c9d9e5e7cb3fe2dfb03e3c467f67f9412f10d0fd5ec -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: This is a digitally signed message part URL: From Roland.vanRijswijk at surfnet.nl Mon Jul 21 11:21:58 2014 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Mon, 21 Jul 2014 13:21:58 +0200 Subject: [Opendnssec-develop] Re: Your Confluence license maintenance expires in 30 days. Contact Atlassian or remind me later. In-Reply-To: <1405933035.5551.1.camel@mine> References: <1405933035.5551.1.camel@mine> Message-ID: <53CCF7D6.1030606@surfnet.nl> Hi Jerry, Jerry Lundstr?m wrote: > Our Atlassian licenses are expiring, can you look at this for all our > sites? > > "Your Confluence license maintenance expires in 30 days. Contact > Atlassian or remind me later." I have a reminder in my calendar (each year) to renew the licenses. Don't worry, I'll take care of this on time ;-) Cheers, Roland -- -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4412 bytes Desc: S/MIME Cryptographic Signature URL: From sara at sinodun.com Mon Jul 21 15:58:42 2014 From: sara at sinodun.com (Sara Dickinson) Date: Mon, 21 Jul 2014 11:58:42 -0400 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.18 Message-ID: <386A4444-3053-4AB0-9D0B-3E638BB164AF@sinodun.com> All, Version 1.3.18 of OpenDNSSEC has now been released: Updates: * OPENDNSSEC-620: conf.xml: New options: for both enforcer and signer, and for the signer. * Build: Fixed various OpenBSD compatibility issues found by Patrik Lundin . * New tool: ods-getconf: to retrieve a configuration value from conf.xml given an expression. Bugfixes: * OPENDNSSEC-632: ods-ksmutil: 'zone add' command when zonelist.xml.backup can't be written zone is still added to database, solved it by checking the zonelist.xml.backup is writable before adding zones, and add error message when add zone failed. * OPENDNSSEC-624: memory leak when signer failed, solved it by add ldns_rr_free(signature) in libhsm.c * simple-dnskey-mailer.sh: Fix syntax error. (by Patrik Lundin https://github.com/eest) * libhsm: Fixed a few other memory leaks. Documentation: * http://wiki.opendnssec.org/display/DOCS13 Download: * https://dist.opendnssec.org/source/opendnssec-1.3.18.tar.gz * https://dist.opendnssec.org/source/opendnssec-1.3.18.tar.gz.sig * Checksum SHA1: 6c860096257955b3559c1d42cf59047332f3d1ee * Checksum SHA256: e61d23ae0cc57b6e09d408bade6872fe5241896c61a03e8bc5ceeb65df13a676 //OpenDNSSEC team From sara at sinodun.com Mon Jul 21 15:58:48 2014 From: sara at sinodun.com (Sara Dickinson) Date: Mon, 21 Jul 2014 11:58:48 -0400 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.6 Message-ID: <3AA0FFE9-7C3B-4775-AD12-F1D3F4695761@sinodun.com> All, Version 1.4.6 of OpenDNSSEC is now available. This is the latest stable release. Updates: * Signer Engine: Print secondary server address when logging notify reply errors. * Build: Fixed various OpenBSD compatibility issues found by Patrik Lundin . * OPENDNSSEC-621: conf.xml: New options: for both enforcer and signer, and for the signer. * New tool: ods-getconf: to retrieve a configuration value from conf.xml given an expression. Bugfixes: * OPENDNSSEC-469: ods-ksmutil: 'zone add' command when zonelist.xml.backup can't be written zone is still added to database, solved it by checking the zonelist.xml.backup is writable before adding zones, and add error message when add zone failed. * OPENDNSSEC-617: Signer Engine: Fix DNS Input Adapter to not reject zone the first time due to RFC 1982 serial arethmetic. * OPENDNSSEC-619: memory leak when signer failed, solved it by add ldns_rr_free(signature) in libhsm.c * OPENDNSSEC-627: Signer Engine: Unable to update serial after restart when the backup files has been removed. * OPENDNSSEC-628: Signer Engine: Ingored notifies log level is changed from debug to info. * OPENDNSSEC-630: Signer Engine: Fix inbound zone transfer for root zone. * libhsm: Fixed a few other memory leaks. * simple-dnskey-mailer.sh: Fix syntax error. (by Patrik Lundin https://github.com/eest) Documentation: * http://wiki.opendnssec.org/display/DOCS Download: * https://dist.opendnssec.org/source/opendnssec-1.4.6.tar.gz * https://dist.opendnssec.org/source/opendnssec-1.4.6.tar.gz.sig * Checksum SHA1: 2318b31546d0d4118cd03b9591ba76d259e1b0b0 * Checksum SHA256: 53f9c454f331822925d76c9d9e5e7cb3fe2dfb03e3c467f67f9412f10d0fd5ec //OpenDNSSEC team From sara at sinodun.com Thu Jul 24 22:19:33 2014 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 24 Jul 2014 18:19:33 -0400 Subject: [Opendnssec-develop] RE: OpenDNSSEC Project management Message-ID: Hi All, Benno and I met yesterday to do a handover of the Project Management for OpenDNSSEC. Benno will send out a more general email shortly but in terms of day to day activities Benno is now the interim Project Manager. He will be in this role for the next few weeks and then Jakob will be taking over as Project Manager at the end of August. I would like to wish everyone in the the team and the project all the best for the future! Regards Sara. From jerry at opendnssec.org Fri Jul 25 05:52:18 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Fri, 25 Jul 2014 07:52:18 +0200 Subject: [Opendnssec-develop] [Fwd: [DNSOP] Changing NSEC3 salts regularly is useless] Message-ID: <1406267538.20968.5.camel@what> Interesting... -------- Forwarded Message -------- > From: Mark Andrews > To: dnsop at ietf.org > Subject: [DNSOP] Changing NSEC3 salts regularly is useless > Date: Fri, 25 Jul 2014 00:02:09 +0200 > > I just sent the following to bind-users. We need to kill the myth > that changing NSEC3 salt provides any real benefit. > > "Actually it is useless to change the salt regularly. Changing the > salt provides no real benefit against discovering the names in a > zone which is the reason people were saying to change the salt. > > The attacker uses cached NSEC3 records. When it gets a cache miss > it asks the servers for the zone, puts the answer in the cache and > continues. When the salt changes it just maintains multiple nsec3 > chains eventually discarding the old nsec3 chain eventually. I > would wait until the new NSEC3 chain has as many cached records as > the old NSEC3 chain. Changing the salt slows things up miniminally > for a very short period of time after the change. Additionally > once you have some names you ask for those names for a non-exisisting > type to quickly pull in part of the new NSEC3 chain you know exists. > > The only reason to change the salt is if you have a collision of > the hashed names. This will be a very very very rare event." > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP at ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From matthijs at nlnetlabs.nl Mon Jul 28 09:10:21 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 28 Jul 2014 11:10:21 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53C4EBC6.5090308@nominet.org.uk> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> Message-ID: <53D6137D.5040604@nlnetlabs.nl> On 07/15/2014 10:52 AM, Si?n Lloyd wrote: > 2.1.1. > "a policy MUST have the containers Signatures, Denial, Keys, Zone and > Parent." > > This is only true for a policy that can control a key rollover; If all I > want is to describe the signing part then "Parent" becomes optional. I > guess this is the same as Yuri's comment? Similar. Yuri's point is if everything in a container is optional. I think a KASP should always describe how to do a key rollover by the way. > 2.1.1.1 > Jitter - I'm not sure that there is a need to define the jitter > algorithm... I can have jitter that only increases signature lifetimes > (i.e. r * j) and it is still just as valid. The algorithm could be given > as an example. I think we do want to define the algorithm: So that if the policy is used in a different implementation, you can expect the same behavior. > 2.1.1.2 > Can Resalt be PT0S? If so what does this mean? Do not resalt. > Can SaltLength be 0? > > (In general by integer you mean positive integer; possibly including > zero? This is all explicit in the current kasp.rnc) Good point. Have to check. Added an issue for that: https://github.com/matje/dnsop-kasp/issues/7 > 2.1.1.3 > Does Repository need to be mandatory? Is this only the case if the > signer uses PKCS11 (I'm not sure of the answer to this; but e.g. "keys > on disc" would need a path instead). If Repository can be anything else than a HSM, like Jerry said, then this may affect the policy model. Thinking twice: probably not, because in KASP we reference to a Repository identifier string. Thanks for the comments! Best regards, Matthijs > > > Sion > > > On 04/07/14 14:23, Matthijs Mekking wrote: >> On 07/04/2014 03:15 PM, Yuri Schaeffer wrote: >>>> We would like to hear your opinions about this and get your >>>> feedback. >>> 1) 2.1.1.2 >>> (...) >>> The choice and case modeling types are not included in the actual >>> data tree. In the case that NSEC is used, the XML example would be: >>> >>> >>> >>> >>> >>> I don't understand what 'choice and case modeling types' are. >> Its YANG language (RFC 6020). Basically you specify in your model that >> you have a choice: Either the schema contains or the schema >> contains . You cannot have both and at the same >> time. A case modeling type is a choice option so to say. >> >> >>> 2) 2.1.1.4. Zone >>> >>> 3. Serial - The format of the serial number in the signed zone. >>> This is one of: "counter", datecounter, unixtime, keep. >>> >>> Perhaps Serial should not be defined as a string but rather a type >>> that has one of the above values. >> I was thinking of that too. I'll add that as an issue to be resolved. >> >> >>> 3) 2.1.1.4 >>> It is unclear which values in the Zone>SOA container are optional. >> Ok, I'll take a look. >> >> >>> 4) If everything in the parent container is optional, why MUST we have >>> a parent container? >> This can probably be a MAY. We started with kasp.rnc with this document >> and then relaxed some rules. >> >> >> I created issues for these in github: >> https://github.com/matje/dnsop-kasp/issues. >> >> Thanks Yuri! >> >> Best regards, >> Matthijs >> >>> _______________________________________________ >>> Opendnssec-develop mailing list >>> Opendnssec-develop at lists.opendnssec.org >>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop >>> >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From sion at nominet.org.uk Mon Jul 28 10:30:07 2014 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Mon, 28 Jul 2014 11:30:07 +0100 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53D6137D.5040604@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> <53D6137D.5040604@nlnetlabs.nl> Message-ID: <53D6262F.6060908@nominet.org.uk> On 28/07/14 10:10, Matthijs Mekking wrote: > On 07/15/2014 10:52 AM, Si?n Lloyd wrote: >> 2.1.1.1 >> Jitter - I'm not sure that there is a need to define the jitter >> algorithm... I can have jitter that only increases signature lifetimes >> (i.e. r * j) and it is still just as valid. The algorithm could be given >> as an example. > I think we do want to define the algorithm: So that if the policy is > used in a different implementation, you can expect the same behavior. I don't agree... If I have an existing implementation that uses a different, but equally valid, algorithm then I can not describe my system using this document. That would seem to be an unnecessary restriction. The more generic solution would be to define jitter as the maximum a signature can vary from the defined lifetime - what distribution that variation takes is implementation specific. Sion From yuri at nlnetlabs.nl Mon Jul 28 11:29:26 2014 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Mon, 28 Jul 2014 13:29:26 +0200 Subject: [Opendnssec-develop] kasp duration notation Message-ID: <53D63416.7040304@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It has come to my attention we have a problem in our date notation. We accept (and output) this: P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W which is according to ISO 8601. Xmlschema used xsd:duration, which is "inspired by"[1] ISO 8601. -HOWEVER- It does not support nor mention the week notation I propose to redefine our date notation as "xsd:duration" rather than "ISO 8601". This makes it possible to use existing xml checking tools. //Yuri [1] http://www.w3.org/TR/xmlschema-2/#duration -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPWNBYACgkQI3PTR4mhavh07QCdFog9QknBXlCUycsMr9Cfu3Jn xyUAn3413Omf67b9oCXtkQNOalWDe6yK =Ic4w -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Jul 28 11:49:59 2014 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Mon, 28 Jul 2014 12:49:59 +0100 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D63416.7040304@nlnetlabs.nl> References: <53D63416.7040304@nlnetlabs.nl> Message-ID: <53D638E7.7040000@nominet.org.uk> On 28/07/14 12:29, Yuri Schaeffer wrote: > It has come to my attention we have a problem in our date notation. > > We accept (and output) this: P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W > which is according to ISO 8601. > Xmlschema used xsd:duration, which is "inspired by"[1] ISO 8601. -HOWEVER- > It does not support nor mention the week notation > > I propose to redefine our date notation as "xsd:duration" rather than > "ISO 8601". This makes it possible to use existing xml checking tools. > So we deprecate the weeks option? I don't think that will be a problem so long as there is a real benefit for us and/or the users... Sion > //Yuri > > > [1] http://www.w3.org/TR/xmlschema-2/#duration > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at nlnetlabs.nl Mon Jul 28 11:59:55 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 28 Jul 2014 13:59:55 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53D6262F.6060908@nominet.org.uk> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> <53D6137D.5040604@nlnetlabs.nl> <53D6262F.6060908@nominet.org.uk> Message-ID: <53D63B3B.7080705@nlnetlabs.nl> On 07/28/2014 12:30 PM, Si?n Lloyd wrote: > On 28/07/14 10:10, Matthijs Mekking wrote: >> On 07/15/2014 10:52 AM, Si?n Lloyd wrote: >>> 2.1.1.1 >>> Jitter - I'm not sure that there is a need to define the jitter >>> algorithm... I can have jitter that only increases signature lifetimes >>> (i.e. r * j) and it is still just as valid. The algorithm could be given >>> as an example. >> I think we do want to define the algorithm: So that if the policy is >> used in a different implementation, you can expect the same behavior. > > I don't agree... If I have an existing implementation that uses a > different, but equally valid, algorithm then I can not describe my > system using this document. That would seem to be an unnecessary > restriction. > > The more generic solution would be to define jitter as the maximum a > signature can vary from the defined lifetime - what distribution that > variation takes is implementation specific. It depends on why the policy includes a jitter. Is it to control the range or is it there to control the signature distribution? If the former, then we can define the jitter to be the varied range. If the latter, I think the algorithm must be defined. Best regards, Matthijs > > Sion > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From matthijs at nlnetlabs.nl Mon Jul 28 12:01:24 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 28 Jul 2014 14:01:24 +0200 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D638E7.7040000@nominet.org.uk> References: <53D63416.7040304@nlnetlabs.nl> <53D638E7.7040000@nominet.org.uk> Message-ID: <53D63B94.2090605@nlnetlabs.nl> On 07/28/2014 01:49 PM, Si?n Lloyd wrote: > On 28/07/14 12:29, Yuri Schaeffer wrote: >> It has come to my attention we have a problem in our date notation. >> >> We accept (and output) this: P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W >> which is according to ISO 8601. >> Xmlschema used xsd:duration, which is "inspired by"[1] ISO 8601. -HOWEVER- >> It does not support nor mention the week notation >> >> I propose to redefine our date notation as "xsd:duration" rather than >> "ISO 8601". This makes it possible to use existing xml checking tools. >> > > So we deprecate the weeks option? I don't think that will be a problem > so long as there is a real benefit for us and/or the users... Does this require a migration script? People may have policies that include P[n]W notations. Best regards, Matthijs > > Sion > >> //Yuri >> >> >> [1] http://www.w3.org/TR/xmlschema-2/#duration >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From sion at nominet.org.uk Mon Jul 28 12:28:39 2014 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Mon, 28 Jul 2014 13:28:39 +0100 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53D63B3B.7080705@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> <53D6137D.5040604@nlnetlabs.nl> <53D6262F.6060908@nominet.org.uk> <53D63B3B.7080705@nlnetlabs.nl> Message-ID: <53D641F7.7090901@nominet.org.uk> On 28/07/14 12:59, Matthijs Mekking wrote: > On 07/28/2014 12:30 PM, Si?n Lloyd wrote: >> On 28/07/14 10:10, Matthijs Mekking wrote: >>> On 07/15/2014 10:52 AM, Si?n Lloyd wrote: >>>> 2.1.1.1 >>>> Jitter - I'm not sure that there is a need to define the jitter >>>> algorithm... I can have jitter that only increases signature lifetimes >>>> (i.e. r * j) and it is still just as valid. The algorithm could be given >>>> as an example. >>> I think we do want to define the algorithm: So that if the policy is >>> used in a different implementation, you can expect the same behavior. >> I don't agree... If I have an existing implementation that uses a >> different, but equally valid, algorithm then I can not describe my >> system using this document. That would seem to be an unnecessary >> restriction. >> >> The more generic solution would be to define jitter as the maximum a >> signature can vary from the defined lifetime - what distribution that >> variation takes is implementation specific. > It depends on why the policy includes a jitter. Is it to control the > range or is it there to control the signature distribution? If the > former, then we can define the jitter to be the varied range. If the > latter, I think the algorithm must be defined. > > My understanding of jitter is that it is to spread signature expiry to reduce peak load on the signer... So I guess I'm arguing for the former and leaving the implementation details out of the policy. Sion From matthijs at nlnetlabs.nl Mon Jul 28 12:36:17 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 28 Jul 2014 14:36:17 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53D641F7.7090901@nominet.org.uk> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> <53D6137D.5040604@nlnetlabs.nl> <53D6262F.6060908@nominet.org.uk> <53D63B3B.7080705@nlnetlabs.nl> <53D641F7.7090901@nominet.org.uk> Message-ID: <53D643C1.4000703@nlnetlabs.nl> On 07/28/2014 02:28 PM, Si?n Lloyd wrote: > On 28/07/14 12:59, Matthijs Mekking wrote: >> On 07/28/2014 12:30 PM, Si?n Lloyd wrote: >>> On 28/07/14 10:10, Matthijs Mekking wrote: >>>> On 07/15/2014 10:52 AM, Si?n Lloyd wrote: >>>>> 2.1.1.1 >>>>> Jitter - I'm not sure that there is a need to define the jitter >>>>> algorithm... I can have jitter that only increases signature lifetimes >>>>> (i.e. r * j) and it is still just as valid. The algorithm could be given >>>>> as an example. >>>> I think we do want to define the algorithm: So that if the policy is >>>> used in a different implementation, you can expect the same behavior. >>> I don't agree... If I have an existing implementation that uses a >>> different, but equally valid, algorithm then I can not describe my >>> system using this document. That would seem to be an unnecessary >>> restriction. >>> >>> The more generic solution would be to define jitter as the maximum a >>> signature can vary from the defined lifetime - what distribution that >>> variation takes is implementation specific. >> It depends on why the policy includes a jitter. Is it to control the >> range or is it there to control the signature distribution? If the >> former, then we can define the jitter to be the varied range. If the >> latter, I think the algorithm must be defined. >> >> > > My understanding of jitter is that it is to spread signature expiry to > reduce peak load on the signer... So I guess I'm arguing for the former > and leaving the implementation details out of the policy. Agree to disagree:) I have created a new issue for this: https://github.com/matje/dnsop-kasp/issues/8 It would be good to hear what others think. Planning to submit this to dnsop list for discussion. Best regards, Matthijs > > Sion > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From jerry at opendnssec.org Mon Jul 28 13:00:31 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Mon, 28 Jul 2014 15:00:31 +0200 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D63B94.2090605@nlnetlabs.nl> References: <53D63416.7040304@nlnetlabs.nl> <53D638E7.7040000@nominet.org.uk> <53D63B94.2090605@nlnetlabs.nl> Message-ID: <1406552431.24990.2.camel@what> On m?n, 2014-07-28 at 14:01 +0200, Matthijs Mekking wrote: > Does this require a migration script? People may have policies that > include P[n]W notations. No they may not, because that violates xsd:duration definition and libxml/relaxng will complain and the KASP is not valid. :) This is how we found it, exported signconf via duration2string() and validated it with the old kc_helper functions. We have not run into this before because OpenDNSSEC 1.x converts all times to seconds on signconf export. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From jerry at opendnssec.org Mon Jul 28 13:01:51 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Mon, 28 Jul 2014 15:01:51 +0200 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D63416.7040304@nlnetlabs.nl> References: <53D63416.7040304@nlnetlabs.nl> Message-ID: <1406552511.24990.3.camel@what> On m?n, 2014-07-28 at 13:29 +0200, Yuri Schaeffer wrote: > I propose to redefine our date notation as "xsd:duration" rather than > "ISO 8601". This makes it possible to use existing xml checking tools. +1 PnW is not part of xsd:duration definition so remove please. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From sion at nominet.org.uk Mon Jul 28 13:11:34 2014 From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=) Date: Mon, 28 Jul 2014 14:11:34 +0100 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <1406552431.24990.2.camel@what> References: <53D63416.7040304@nlnetlabs.nl> <53D638E7.7040000@nominet.org.uk> <53D63B94.2090605@nlnetlabs.nl> <1406552431.24990.2.camel@what> Message-ID: <53D64C06.805@nominet.org.uk> On 28/07/14 14:00, Jerry Lundstr?m wrote: > On m?n, 2014-07-28 at 14:01 +0200, Matthijs Mekking wrote: >> Does this require a migration script? People may have policies that >> include P[n]W notations. > No they may not, because that violates xsd:duration definition and > libxml/relaxng will complain and the KASP is not valid. :) > > This is how we found it, exported signconf via duration2string() and > validated it with the old kc_helper functions. We have not run into this > before because OpenDNSSEC 1.x converts all times to seconds on signconf > export. > > Ah... sion at sion:~/work/CTE/RDPapers/ithun$ ods-kaspcheck /home/sion/work/opendnssec/install/etc/opendnssec/conf.xml:79: element Interval: Relax-NG validity error : Type duration doesn't allow value 'P1W' So as I understand it this doesn't work currently and we are actually talking about a documentation change? Then the decision is easy... remove it. Sion From yuri at nlnetlabs.nl Mon Jul 28 13:18:11 2014 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Mon, 28 Jul 2014 15:18:11 +0200 Subject: [Opendnssec-develop] kasp draft In-Reply-To: <53D643C1.4000703@nlnetlabs.nl> References: <53B68ADC.8080501@nlnetlabs.nl> <53B6A8EC.1040800@nlnetlabs.nl> <53B6AADE.9060804@nlnetlabs.nl> <53C4EBC6.5090308@nominet.org.uk> <53D6137D.5040604@nlnetlabs.nl> <53D6262F.6060908@nominet.org.uk> <53D63B3B.7080705@nlnetlabs.nl> <53D641F7.7090901@nominet.org.uk> <53D643C1.4000703@nlnetlabs.nl> Message-ID: <53D64D93.1000800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It would be good to hear what others think. Planning to submit this > to dnsop list for discussion. tl;dr: I'm with Sion There is not functional difference in using another distribution, therefore fine to leave it as an implementors choice. Lets have jitter as the parameters to whatever function is used. My motivation: The weight distribution of the algorithm used has *no effect* on any of the timing decisions. The min and max values of the algorithm *do* in fact influence the rollovers. //Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPWTZMACgkQI3PTR4mhavjP3QCgtQvkNwMRVNNFOIfQ6hTx8xrW wC0An3kiZo3vhKaIBp5jghwIFnhMFwrJ =J88w -----END PGP SIGNATURE----- From jerry at opendnssec.org Mon Jul 28 13:18:55 2014 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?Q?Lundstr=F6m?=) Date: Mon, 28 Jul 2014 15:18:55 +0200 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D64C06.805@nominet.org.uk> References: <53D63416.7040304@nlnetlabs.nl> <53D638E7.7040000@nominet.org.uk> <53D63B94.2090605@nlnetlabs.nl> <1406552431.24990.2.camel@what> <53D64C06.805@nominet.org.uk> Message-ID: <1406553535.24990.4.camel@what> On m?n, 2014-07-28 at 14:11 +0100, Si?n Lloyd wrote: > So as I understand it this doesn't work currently and we are actually > talking about a documentation change? Well small code change also but from the users perspective, yes. > Then the decision is easy... remove it. :) -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 643 bytes Desc: This is a digitally signed message part URL: From matthijs at nlnetlabs.nl Mon Jul 28 14:35:50 2014 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Mon, 28 Jul 2014 16:35:50 +0200 Subject: [Opendnssec-develop] kasp duration notation In-Reply-To: <53D64C06.805@nominet.org.uk> References: <53D63416.7040304@nlnetlabs.nl> <53D638E7.7040000@nominet.org.uk> <53D63B94.2090605@nlnetlabs.nl> <1406552431.24990.2.camel@what> <53D64C06.805@nominet.org.uk> Message-ID: <53D65FC6.8030604@nlnetlabs.nl> On 07/28/2014 03:11 PM, Si?n Lloyd wrote: > On 28/07/14 14:00, Jerry Lundstr?m wrote: >> On m?n, 2014-07-28 at 14:01 +0200, Matthijs Mekking wrote: >>> Does this require a migration script? People may have policies that >>> include P[n]W notations. >> No they may not, because that violates xsd:duration definition and >> libxml/relaxng will complain and the KASP is not valid. :) >> >> This is how we found it, exported signconf via duration2string() and >> validated it with the old kc_helper functions. We have not run into this >> before because OpenDNSSEC 1.x converts all times to seconds on signconf >> export. >> >> > > Ah... > > sion at sion:~/work/CTE/RDPapers/ithun$ ods-kaspcheck > /home/sion/work/opendnssec/install/etc/opendnssec/conf.xml:79: element > Interval: Relax-NG validity error : Type duration doesn't allow value 'P1W' If this is ods-kaspcheck 1.x, then... > So as I understand it this doesn't work currently and we are actually > talking about a documentation change? > > Then the decision is easy... remove it. ... +1 Matthijs > > Sion > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop >