From Rickard.Bondesson at iis.se Wed Jan 7 09:16:10 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 7 Jan 2009 10:16:10 +0100 Subject: [Opendnssec-develop] SoftHSM - Signing speed In-Reply-To: <69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B9041199718646602@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 SoftHSM is now working in 64-bit mode. The speed is improved significantly compared with 32-bit mode. With SoftHSM in 64-bit mode RSA1024 key: ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 100000 090107080129230036 6025.85 sig/s RSA2048 key: ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 20000 090107090658261676 1337.67 sig/s > It is on a 4 core 64 bit Sun OS machine. > > With SoftHSM: > > RSA1024 key: > ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 100000 081212083059184661 > 2052.76 sig/s > > RSA2048 key: > ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 20000 081212093603519314 > 386.54 sig/s > > With 64-bit OpenSSL: > > openssl speed rsa1024 -multi 4: 8239.2 sig/s > openssl speed rsa2048 -multi 4: 1368.9 sig/s > > With 32-bit OpenSSL: > > openssl speed rsa1024 -multi 4: 1301.8 sig/s > openssl speed rsa2048 -multi 4: 238.1 sig/s -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWRy2uCjgaNTdVjaAQjm+ggAoNdFF6VF2wY8QW4FILOxFS+LPkGtchml pK5C2Va47fcqxTSPBv7Urt1b0PN8fiQEeoMxAR4AvBxLtXTdkQ3QqySXEGTr2K97 LZC4ZLV0qWbdpGfaW0stzv0SFQtYIuqapA9L2YkKRI7Z3NADUjxhi5VqoQNxLPFI YhBXr6gEi8opXjQeENs5Vq3PQmdVbfXAB3vQB2hp7Kd+wnl4gKwM9MBjl/4Z7Aj9 kCsV/gUtJyJYxdAOcqkMguGZJV+l4mfqTJF/k58N36+8ZiE/VoF3pcJd+yQSv9Lt SVXLOfV5nR34TU+XieE6bQZyzi/FUn1dNiEth5CdrwSZ24cgE6XUrg== =aWML -----END PGP SIGNATURE----- From jakob at kirei.se Wed Jan 7 11:28:32 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 7 Jan 2009 12:28:32 +0100 Subject: [Opendnssec-develop] SoftHSM - Signing speed In-Reply-To: <69830D4127201D4EBD146B9041199718646602@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B9041199718646602@EXCHANGE.office.nic.se> Message-ID: <8311D852-1D0D-47D1-A404-F823DB1726E7@kirei.se> great news Rickard! j From Rickard.Bondesson at iis.se Wed Jan 7 13:27:54 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 7 Jan 2009 14:27:54 +0100 Subject: [Opendnssec-develop] True Random Number Generator Message-ID: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We at .SE are using the Araneus Alea I (a True Random Number Generator on an USB interface, http://www.araneus.fi/products-alea-eng.html) in our current DNSSEC software. Is there any general interest of supporting this or other similar solutions in the SoftHSM? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWSt2uCjgaNTdVjaAQjtxQf5AbMkeZ7wxNwwrCp6nrgqmYYRVOlKBY9G JZGm3TJIfY0BOS8ysq72zLX4cNHWgrQZ9VBunonvei6z0PzFjXSWrdobK6e5qOdv 8cTsuKFh7atiEGDqTa7HBXgK+bjgI+O0ZOVmjoybyUqywh5H8j2+yaEFhjOcGn7/ MINtZ5cqVTZxGyZDulG9zHRWjIHTFUZ5dfCqO/0o9bmNCvD6iRY0ZZxe96kdXgIK bc/6rtITHmA3t8uspxnfFCTtNlGXOMbxDPQSmoDKLnLCOOH8n91BPNiEFzlTmDe0 QvDjWunwhA+eupAX7WS/UTg+LXxbgX5Rb//2YjClEzZaXH/Qozf2pw== =msNJ -----END PGP SIGNATURE----- From rick at openfortress.nl Wed Jan 7 14:04:12 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 7 Jan 2009 14:04:12 +0000 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> Message-ID: <20090107140412.GC1204@phantom.vanrein.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rickard, Although you are asking for device support and not for the need for lots of random bits, please allow me to comment on the need of these devices: > We at .SE are using the Araneus Alea I (a True Random Number Generator on an USB interface, http://www.araneus.fi/products-alea-eng.html) in our current DNSSEC software. Is there any general interest of supporting this or other similar solutions in the SoftHSM? A good random source (which cannot be tapped ro replayed) is of the utmost importance for DSA signing, because every signature needs a fresh random number. (If not, and you'd know that two sigs were made with the same "random" number, they'd reduce to a set of two equations with two unknown variables, which are trivially solved. NSA may have forgotten to mention that when introducing DSA.) RSA is a different matter. With that, random material is only needed when generating keys. Unless you are signing loads and loads of domains you need nothing to speed up random generation for that, I'd imagine. A _good_ source is still advisable of course, and hardware is so incoherent it produces far better generators than software. When signing for DNSSEC, the choice between RSA and DSA is easy: - RSA keysizes can be increased as security demands; - RSA needs no masses of random material when in signing operation; - RSA validates much quicker than DSA. Hope this helps, Rick van Rein OpenFortress Digital signatures http://openfortress.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html iD8DBQFJZLYvFBGpwol1RgYRAsDtAJ9aZlLahiHOhzX4ZJ5ISRsQv35G7ACfSIR/ 5afZyfaXCEbjIb1M+feaBG0= =m4wU -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Wed Jan 7 14:11:11 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 07 Jan 2009 15:11:11 +0100 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> Message-ID: <4964B7FF.4080704@surfnet.nl> Hi Rickard, If it's not too much work, I think it would make sense to support such devices. Cheers, Roland. Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > We at .SE are using the Araneus Alea I (a True Random Number Generator on an USB interface, http://www.araneus.fi/products-alea-eng.html) in our current DNSSEC software. Is there any general interest of supporting this or other similar solutions in the SoftHSM? > > // Rickard > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSWSt2uCjgaNTdVjaAQjtxQf5AbMkeZ7wxNwwrCp6nrgqmYYRVOlKBY9G > JZGm3TJIfY0BOS8ysq72zLX4cNHWgrQZ9VBunonvei6z0PzFjXSWrdobK6e5qOdv > 8cTsuKFh7atiEGDqTa7HBXgK+bjgI+O0ZOVmjoybyUqywh5H8j2+yaEFhjOcGn7/ > MINtZ5cqVTZxGyZDulG9zHRWjIHTFUZ5dfCqO/0o9bmNCvD6iRY0ZZxe96kdXgIK > bc/6rtITHmA3t8uspxnfFCTtNlGXOMbxDPQSmoDKLnLCOOH8n91BPNiEFzlTmDe0 > QvDjWunwhA+eupAX7WS/UTg+LXxbgX5Rb//2YjClEzZaXH/Qozf2pw== > =msNJ > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Rickard.Bondesson at iis.se Wed Jan 7 14:33:28 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 7 Jan 2009 15:33:28 +0100 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <20090107140412.GC1204@phantom.vanrein.org> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > RSA is a different matter. With that, random material is > only needed when generating keys. Unless you are signing > loads and loads of domains you need nothing to speed up > random generation for that, I'd imagine. > A _good_ source is still advisable of course, and hardware is > so incoherent it produces far better generators than software. > > When signing for DNSSEC, the choice between RSA and DSA is easy: > - RSA keysizes can be increased as security demands; > - RSA needs no masses of random material when in signing operation; > - RSA validates much quicker than DSA. I agree that RSA is a good choice. Currently there is no support for DSA in SoftHSM. Hardware TRNG is thereby, as for OpenDNSSEC, not a high priority, just a nice thing but would need device dependent code since there is no standardized interface. I will make it easy to extend the SoftHSM with such code. > Hope this helps, Yeah, thank you. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWS9OOCjgaNTdVjaAQiQtAf/T9nSE6hZfZR8v8I6Wh6X5B/qh0AOvPFI Advk2YAb/WAG7VBEAIH9EyLifQpRtAJqBiePK1VlCtufT2Ka8wCISymwrnydBsmL +6YrSlotEJFYxscP2wTwjrSoZ7IBFf3C4x8mnGFY1t/8rtbod5iWbaJqzhUpOkuv SnPKGmaeC+UV4N8QwC0LehXoJkaFUpHJdrirGtP1ufEH/Dfk+dtHReiFCYimwzo4 Nt29oNr5PkMia8MkzCZXmUQEQ9+FK0D7xqpqOU79ClX7Z4jGsh6zkkKtJmYBOg1P CLJ9IywAdXKrzlUm0g9ALtqXjJTQFwkMcH/TTd/fxKDcv7UknOjmhg== =tCSI -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Wed Jan 7 17:30:46 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Wed, 7 Jan 2009 17:30:46 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <494A6B19.3080005@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> Message-ID: On 18 Dec 2008, at 15:24, Jelte Jansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Dickinson wrote: >>> >> Over the holiday, I will write up a short document describing what I >> think the different parts are, what they do and how they link >> together. >> I will send that round and maybe we can use it as the basis for some >> discussion in the new year. >> > > I'll be back up and running on the fifth, i'd say give me one or two > days to get going and hold a conference call on wednesday or thursday? > > (btw i think roy wanted to plan a face2face meeting somewhere later in > january, which i already thought was a good idea, and now i think it > is > an absolute necessity) As promised here are my thoughts. This document is by no means complete and is only intended to reflect my understanding of what we are doing. Therefore, it will need some discussion :) As for a meeting, I am skiing 17th - 25th but available all the rest of the month. HTH John -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenDNSSEC Design.pdf Type: application/pdf Size: 222170 bytes Desc: not available URL: -------------- next part -------------- From Rickard.Bondesson at iis.se Thu Jan 8 08:21:13 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 8 Jan 2009 09:21:13 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > As promised here are my thoughts. This document is by no > means complete and is only intended to reflect my > understanding of what we are doing. Therefore, it will need > some discussion :) Great! As for the security module location, variable in the database, I assume it also contains the slotID and some kind of object identifier (like the CKA_ID or CKA_LABEL). We should also discuss our commitment and how much time we can spend on this project. This would make it easier to make a more detailed time schedule and resource planning. As for me, I am working 100 % with this project (SoftHSM). I can also contribute with project administration, like a more detailed project plan, time plan, and calling for meetings (if this is OK by Roy (knows that he has a lot to do in other projects)). > As for a meeting, I am skiing 17th - 25th but available all > the rest of the month. Perhaps we could have one in next week (not Monday, I have a full day meeting) on Jabber? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWW3eeCjgaNTdVjaAQgg9Qf/S72S2VBHAaiwiAG/5JZUzlXzy/IKtbYl poFnL+YM249pg7ByFEcsj1yj7IBw3NmgeBpgWSTPU4Z3jOFjxLg0nMwuXks5228B BYJV+z1PfT4WjCsySNimGB5dyxu+K+wqD08MMgsnO6KDhBj1nFk1PeM/mH9X4yWx U91eM/1bRkHzuUsQqCLCuf8oueUXa27bTdmhimmiKO25kYJPlcCHP37pau1Dwla2 qXrr7kctQa3j+r70nrc0rWVDUgnV/Nlx7yN4s8lRKfqQckLVuPPSfksNsVAz9pXe kKiOsxkccpp/K0UriMfkgjqgJwlu8cFLLJjlDoIPKiWyeJGcCN8OLw== =x/Wx -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Thu Jan 8 08:27:46 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 08 Jan 2009 09:27:46 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> Message-ID: <4965B902.7070909@surfnet.nl> Hi guys, As promised to Roy last year, I've set up a skeleton for a test framework to test if a PKCS #11 module has all the capabilities required to work with OpenDNSSEC. I have two questions for you: - Can you try to think of the functionality a PKCS #11 would need to have to interoperate with OpenDNSSEC (think of: which attributes should be supported, which mechanisms, which functions, which minimum key sizes, etc.) - Is there a shared source control repository (like subversion) where I can manage the code (I'm managing it in my own svn repository at the moment). Cheers, Roland. Rickard Bondesson wrote: >> As promised here are my thoughts. This document is by no >> means complete and is only intended to reflect my >> understanding of what we are doing. Therefore, it will need >> some discussion :) > > Great! > > As for the security module location, variable in the database, I assume it also contains the slotID and some kind of object identifier (like the CKA_ID or CKA_LABEL). > > We should also discuss our commitment and how much time we can spend on this project. This would make it easier to make a more detailed time schedule and resource planning. > > As for me, I am working 100 % with this project (SoftHSM). I can also contribute with project administration, like a more detailed project plan, time plan, and calling for meetings (if this is OK by Roy (knows that he has a lot to do in other projects)). > >> As for a meeting, I am skiing 17th - 25th but available all >> the rest of the month. > > Perhaps we could have one in next week (not Monday, I have a full day meeting) on Jabber? > > // Rickard ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Rickard.Bondesson at iis.se Thu Jan 8 08:47:20 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 8 Jan 2009 09:47:20 +0100 Subject: SV: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <4965B902.7070909@surfnet.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <4965B902.7070909@surfnet.nl> Message-ID: <69830D4127201D4EBD146B9041199718646694@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > - Can you try to think of the functionality a PKCS #11 would > need to have to interoperate with OpenDNSSEC (think of: which > attributes should be supported, which mechanisms, which > functions, which minimum key sizes, etc.) > > - Is there a shared source control repository (like > subversion) where I can manage the code (I'm managing it in > my own svn repository at the moment). The svn repository is managed by Jakob. He can give you credentials. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWW9mOCjgaNTdVjaAQgaNQf+JufVHzKqOCbxu7G0oJkXGJwrz3Rpb+qG vLXCWk2hyol7xLFzOT15M5aDKCiNzIbNggoDuXtgCNhaN2SlOYokvAcBfdHw9RJo ep//V7xdytfWaqzdIpmKakPsipHT67KiBE+kVig0VXy1VYh7fxVQPvtQIYCMuL0s LkvH3LI+CGcHCZuQfIItQdvNGJjeEZQaGlVIQNb3sVmP6V/RY0U28ITCl0eQwWe7 n/L3jxHBh1JFvBpw28VzbjmYNRuGd5kV5X9KOEQIbJeKvZCXAo8Dx0hlBcsf/YCv Ojq8oZtJKePCgY4jHH5TZgASG9Tc7br/opLAyQg4022YRIJUoLcPFg== =G5Gk -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Thu Jan 8 11:25:50 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 8 Jan 2009 11:25:50 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> Message-ID: <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> On 8 Jan 2009, at 08:21, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> As promised here are my thoughts. This document is by no >> means complete and is only intended to reflect my >> understanding of what we are doing. Therefore, it will need >> some discussion :) > > Great! > > As for the security module location, variable in the database, I > assume it also contains the slotID and some kind of object > identifier (like the CKA_ID or CKA_LABEL). Yes it will. We have been thinking about a URL that contains the id or label as well as the path to the pkcs11 library. Something like pkcs11:///usr/lib/my_pkcs11_lib.so?slot=1&id=123&label=mykey However, when I started playing with the code I did start wondering if that would be worth the effort. It might be easier to just have different fields in the table (saves all the URL parsing code after all). That is (I think) something that will come out as part of working on the prototype. > > We should also discuss our commitment and how much time we can spend > on this project. This would make it easier to make a more detailed > time schedule and resource planning. Yes. > As for me, I am working 100 % with this project (SoftHSM). I can > also contribute with project administration, like a more detailed > project plan, time plan, and calling for meetings (if this is OK by > Roy (knows that he has a lot to do in other projects)). > > >> As for a meeting, I am skiing 17th - 25th but available all >> the rest of the month. > > Perhaps we could have one in next week (not Monday, I have a full > day meeting) on Jabber? I think a conference call would be better if someone can provide the technology but jabber is fine as well. We can use a room on my jabber server if necessary. Here is a doodle if that helps get this arranged http://www.doodle.com/2fpcx8smn4p8kiaa John From jelte at NLnetLabs.nl Thu Jan 8 11:31:39 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Thu, 08 Jan 2009 12:31:39 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> Message-ID: <4965E41B.60305@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dickinson wrote: >>> As for a meeting, I am skiing 17th - 25th but available all >>> the rest of the month. >> >> Perhaps we could have one in next week (not Monday, I have a full day >> meeting) on Jabber? > > I think a conference call would be better if someone can provide the > technology but jabber is fine as well. We can use a room on my jabber > server if necessary. Here is a doodle if that helps get this arranged > http://www.doodle.com/2fpcx8smn4p8kiaa > +1 or actually, both a call and a jabber room would be best i think i can set up a conference call for sip and pots, i'll post some details so you can try it out if you want. I prefer wednesday, and while i'm at it i think a specific agenda would be a good idea ;) (i have yet to read your doc btw) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkll5BcACgkQ4nZCKsdOncUoTACfXpNfOjF42m9rxPbO8IKpFa2K Da8AoM6pZ8vIGOeT8oKFu+rDcrUYmTED =1y65 -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Thu Jan 8 12:25:43 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 8 Jan 2009 12:25:43 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <4965E41B.60305@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> <4965E41B.60305@NLnetLabs.nl> Message-ID: <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> On 8 Jan 2009, at 11:31, Jelte Jansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Dickinson wrote: >>>> As for a meeting, I am skiing 17th - 25th but available all >>>> the rest of the month. >>> >>> Perhaps we could have one in next week (not Monday, I have a full >>> day >>> meeting) on Jabber? >> >> I think a conference call would be better if someone can provide the >> technology but jabber is fine as well. We can use a room on my jabber >> server if necessary. Here is a doodle if that helps get this arranged >> http://www.doodle.com/2fpcx8smn4p8kiaa >> > > +1 > > or actually, both a call and a jabber room would be best i think > > i can set up a conference call for sip and pots, i'll post some > details > so you can try it out if you want. > > I prefer wednesday, and while i'm at it i think a specific agenda > would > be a good idea ;) OK - here is a start - please add anything missing. Agenda Nominate someone to take minutes - I suggest the last person to fill in the doodle :) With reference to the document I distributed 1. Agree what the components are 1a. Discuss any known contradictions on the wiki 1b. How do the components interface with each other in both the prototype and final systems 1c. Discuss technology to be used for each component 1d. Do we know the requirements for each component? 1e. Answer the question Matthijs asked in his email (see below) 2. Agree who is developing each component 3. Discussion of the commitment needed for each component and available from each party. 4. Brief update on the state of each component where possible 5. Discuss and agree plan to move forward 5a. Discuss timeline for whole project 5b. Decide on milestones for each component 5c. What about testing? 6. Decide on date of next meeting 7. Agree actions 7a. Who writes minutes 7b. Who is writing any documentation still needed 7c. Who updates the wiki based on this meeting 7d. Other... List of questions from Matthijs 1. From the opendnssec.org website, I assume that the Signer has to determine the inception and expiration times on signatures. It can determine this from the refresh interval. (Ok, not a real question:)) 2. What's the difference between zone resigning interval and signature refresh interval? Imho, they are the same, but described differently. 3. What is the priority of changing security parameters? For example, it could be that the signature validity period has changed. Does this need to be applied to all signatures directly, or are they applied to upcoming generated signatures only? 4. What is meant with signature jitter and clockskew? Does this affect the zone content? If so, in what way? From jad at jadickinson.co.uk Thu Jan 8 12:36:43 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 8 Jan 2009 12:36:43 +0000 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> Message-ID: On 7 Jan 2009, at 14:33, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> RSA is a different matter. With that, random material is >> only needed when generating keys. Unless you are signing >> loads and loads of domains you need nothing to speed up >> random generation for that, I'd imagine. >> A _good_ source is still advisable of course, and hardware is >> so incoherent it produces far better generators than software. >> >> When signing for DNSSEC, the choice between RSA and DSA is easy: >> - RSA keysizes can be increased as security demands; >> - RSA needs no masses of random material when in signing operation; >> - RSA validates much quicker than DSA. > > I agree that RSA is a good choice. Currently there is no support for > DSA in SoftHSM. Hardware TRNG is thereby, as for OpenDNSSEC, not a > high priority, just a nice thing but would need device dependent > code since there is no standardized interface. I will make it easy > to extend the SoftHSM with such code. I did use one of those Araneus things once. I seem to remember it being easy to create a file full of random data. Would it be better to have the Araneus appear as an alternative /dev/random device that you point the softHSM at? Or am I completely misunderstanding? One other thing that I thought would be good is if the softHSM can be complete enough to work with an OpenSSL pkcs11 engine (like the OpenSC one). I know we don't want that for OpenDNSSEC but it might be a good feature to have. WDYT? Thanks John From Rickard.Bondesson at iis.se Thu Jan 8 12:57:43 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 8 Jan 2009 13:57:43 +0100 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I did use one of those Araneus things once. I seem to remember it > being easy to create a file full of random data. Would it be > better to > have the Araneus appear as an alternative /dev/random device > that you > point the softHSM at? Or am I completely misunderstanding? I would implement an interface to the internal RNG that would pull random data from the USB via libusb. But do you mean that the user should manually pull data from the Araneus and mount this. This source of data would then only last for a limited time, so I think it is better to let the SoftHSM do the pulling. > One other thing that I thought would be good is if the > softHSM can be > complete enough to work with an OpenSSL pkcs11 engine (like > the OpenSC > one). I know we don't want that for OpenDNSSEC but it might > be a good > feature to have. WDYT? SoftHSM will be PKCS11 compliant, but will not implement all of the functions. I have not checked if these demand more functionality than we do, but it is sure a good thing to do. However, if we want more functionality like certificate or symmetric key handling then SoftHSM must be redesigned. With, as mentioned in a conversation in December, a loss of performance. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWX4RuCjgaNTdVjaAQgksgf9EqY2BgDC7X+WQrCn3+7vGWEXT2F0LjFi 2anlQ30+B8Gdel8vjhEAlGoKbTGXRHGJCGMhaRNsW7HqyCru7c3p8v/FTvzxvfBV OZDok2VzKIKTeWX+baiRETMiVOxsD5TLyqIvDBs/lZTwIYPc14OCRBl82LCL7Ulo 5rNqSa2NScz+2OqKhvKvnqV7z7/CGCzGM2+vwuwckGCCpilN1+AIcOFXtTUA0brV Hb6/+Zzanm5OVLvv4C7/09yL/LW2sG1TLzPdXQxPqO3OnRTyvMk0CRWzEI0VYISR YzkZneVIqfZN6E6b0Kf6+3Be2KipYeapKMbpoG3J3Eb/+smNaeCwaQ== =MHPB -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Thu Jan 8 13:35:30 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 8 Jan 2009 13:35:30 +0000 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> Message-ID: <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> On 8 Jan 2009, at 12:57, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> I did use one of those Araneus things once. I seem to remember it >> being easy to create a file full of random data. Would it be >> better to >> have the Araneus appear as an alternative /dev/random device >> that you >> point the softHSM at? Or am I completely misunderstanding? > > I would implement an interface to the internal RNG that would pull > random data from the USB via libusb. > But do you mean that the user should manually pull data from the > Araneus and mount this. This source of data would then only last for > a limited time, so I think it is better to let the SoftHSM do the > pulling. Sorry, I wasn't clear. They were two separate threads of thought. What I meant is an application?? or kernel module?? that gets random data via libusb and presents it as something like /dev/random to the applications that might want to use it. So any application that allows you to specify the random device (like the -r option to dnssec-keygen) can use it. >> One other thing that I thought would be good is if the >> softHSM can be >> complete enough to work with an OpenSSL pkcs11 engine (like >> the OpenSC >> one). I know we don't want that for OpenDNSSEC but it might >> be a good >> feature to have. WDYT? > > SoftHSM will be PKCS11 compliant, but will not implement all of the > functions. I have not checked if these demand more functionality > than we do, but it is sure a good thing to do. However, if we want > more functionality like certificate or symmetric key handling then > SoftHSM must be redesigned. With, as mentioned in a conversation in > December, a loss of performance. I agree this should only be done if it is a question of supporting the correct attributes or something simple. Adding certs or symmetric keys is too much. I did try getting the opensc engine to talk to softHSM and it kept complaining about things (they seemed minor) but I didn't note down what they were - I will try again and post a summary. John From Rickard.Bondesson at iis.se Thu Jan 8 13:41:07 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 8 Jan 2009 14:41:07 +0100 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B90411997186466D2@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Sorry, I wasn't clear. They were two separate threads of > thought. What I meant is an application?? or kernel module?? > that gets random data via libusb and presents it as something > like /dev/random to the applications that might want to use > it. So any application that allows you to specify the random > device (like the -r option to dnssec-keygen) can use it. Yeah. That is a good idea. > I agree this should only be done if it is a question of > supporting the correct attributes or something simple. Adding > certs or symmetric keys is too much. I did try getting the > opensc engine to talk to softHSM and it kept complaining > about things (they seemed minor) but I didn't note down what > they were - I will try again and post a summary. Ohh. Bug reports are always nice :) // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWYCc+CjgaNTdVjaAQi3DQf/aJEYzGuLMV6/Fc6l/aF/7Ur9wHOhatpM i6azbCCyLWaIDA1Jkov03x2dlP/j6w2f8O+gclz7wtmNa5G7EENpJABQ3XAaVdqK CxemNV366g1Xgh7uwg8hi7k67VouErthe7DtmLFUCT6HzdqaOy07gluJiP65lZEk l6Es4H/4ooamH7qk1af7Kp6QCDxzc2XU0LJrK0iURJ9jYHk0YxhoELXf/pyj0h9x h+PNGie0ZGj0Hhg9Amt4ECOE8Dv4BKMualyuewb3nHplQC5V4HSO05WMrVAegphH 0jHaPidHYvEgwFPBopfYq5UW9dpdrco+6A6dNYeeXdzf72o66NB7lQ== =O0OZ -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Fri Jan 9 10:16:58 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 9 Jan 2009 11:16:58 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> <4965E41B.60305@NLnetLabs.nl> <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B9041199718646722@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > OK - here is a start - please add anything missing. > > Agenda > > Nominate someone to take minutes - I suggest the last person to fill > in the doodle :) > > With reference to the document I distributed > > 1. Agree what the components are > 1a. Discuss any known contradictions on the wiki > 1b. How do the components interface with each other in both the > prototype and final systems > 1c. Discuss technology to be used for each component > 1d. Do we know the requirements for each component? > 1e. Answer the question Matthijs asked in his email (see below) > > 2. Agree who is developing each component > > 3. Discussion of the commitment needed for each component and > available from each party. > > 4. Brief update on the state of each component where possible > > 5. Discuss and agree plan to move forward > 5a. Discuss timeline for whole project > 5b. Decide on milestones for each component > 5c. What about testing? > > 6. Decide on date of next meeting > > 7. Agree actions > 7a. Who writes minutes > 7b. Who is writing any documentation still needed > 7c. Who updates the wiki based on this meeting > 7d. Other... > > > > List of questions from Matthijs > 1. From the opendnssec.org website, I assume that the Signer has to > determine the inception and expiration times on signatures. It can > determine this from the refresh interval. (Ok, not a real question:)) > > 2. What's the difference between zone resigning interval and signature > refresh interval? Imho, they are the same, but described differently. > > 3. What is the priority of changing security parameters? For > example, it > could be that the signature validity period has changed. Does > this need > to be applied to all signatures directly, or are they applied to > upcoming generated signatures only? > > 4. What is meant with signature jitter and clockskew? Does this affect > the zone content? If so, in what way? +1 Good agenda. How about a meeting on Wednesday at 14:00 CET? Meeting set up as Jelte suggested? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBSWckGuCjgaNTdVjaAQhe9wf2JHQVMQ1F+Y8C6Nq6CSM2/ZzF/q7Q5s86 G0KCZ3f+k9jNRRjy34rtKngsryKnWg4DAyrkaPibC7YBITVV1kM98ykydugvOWV0 jWGGnblCsHmERuk9XC9nP9uZ9U75QtwmP4GRjliEiIH0KDRC7HBoLzOBEkFs7l1I Rgb/neVnPthApYY3MwlsEG2lD3MyUGmwbywl/0EE9DlEtemDqhuwsgJu2tcP4fgs S1Shq3hSwNiK0quypIt3ibJBHZv9avFcqEL5RqgaByivn1EcJow1YhJnlrIEeO+4 5bknjW/a0w08IxUneTc5iXGjqa8YQ6aewtI3jQQu0InxvZL88hA/ =vwnt -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Jan 9 13:38:18 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 09 Jan 2009 14:38:18 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <69830D4127201D4EBD146B9041199718646722@EXCHANGE.office.nic.se> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> <4965E41B.60305@NLnetLabs.nl> <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> <69830D4127201D4EBD146B9041199718646722@EXCHANGE.office.nic.se> Message-ID: <4967534A.4080202@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: > > +1 Good agenda. How about a meeting on Wednesday at 14:00 CET? Meeting set up as Jelte suggested? Wednesday 14:00 CET is fine with me I've set up a conference room at sip:conference at NLnetLabs.nl the pin number is 5227# If you don't have a sip phone or client available, the room should also be available at +31 20 7508314 extension 263 (just dial 263 when olaf's recorded voice starts talking) If you want to test your own connection, the room is up already, just find someone else to dial in too so you won't be lonely ;) Jelte ps. does anyone know of some free software tool to do collaberative drawing? so we can have a whiteboard should we need one? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklnU0oACgkQ4nZCKsdOncXOiwCgkJfYM21n/VlClpj7gU4NQYrR AD4AnjPFKwHesDA6Wz6X9e/xs00AuZ8p =11qc -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Fri Jan 9 14:35:18 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 9 Jan 2009 15:35:18 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <4967534A.4080202@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> <4965E41B.60305@NLnetLabs.nl> <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> <69830D4127201D4EBD146B9041199718646722@EXCHANGE.office.nic.se> <4967534A.4080202@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718646755@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > +1 Good agenda. How about a meeting on Wednesday at 14:00 > CET? Meeting set up as Jelte suggested? We have a lot to discuss, so it is a good idea to also limit the meeting to a maximum of 1.5 hours. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWdgpuCjgaNTdVjaAQihiQf9FYmn4nDTVlwAhNNU37vOYXRzxDFqwO6L ODfic/WLGOuGCNIekp9S0utts88SVE2gP/7N2bFL3FGQhqftwC+n6IszVLHaqrhJ nfWskbLOWkC7hTmvYZeCuTXugpibi9KdoBT399EmLkwTkzBQ6i4iQMlrdt0YhjXM 96rwJRDhIHLz9DO48h3mwzvSEv+bA1Tdj4ShEHwcdnR5DwR+m/X/DMcEfiOLo/FK /wTQkPbv0hCeEfz7tdZOiEamGqj9oXMuX1bL5pnyI5cjtfZ2f+KT1GYun2nKGfrZ EpkNnlbuOWb/2duh4DIplAjeo48qpP8fE94Burr+t64JlvJqmxNC4w== =5rSh -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Mon Jan 12 08:55:59 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 12 Jan 2009 09:55:59 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> Message-ID: <496B059F.5060100@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dickinson wrote: > > As promised here are my thoughts. This document is by no means complete > and is only intended to reflect my understanding of what we are doing. > Therefore, it will need some discussion :) > just to beat the meeting and give us something to think about; what i'm missing from this document is where the actual content of the zones lives. The doc seems to suggest that is is 'xfr upon need'; when some signing of a zone needs to be done; the contents are fetched. This is not as i had understood (rather, i thought the whole system was to be either an actual master or an 'active' slave to another master; keeping the zone data synced as much as possible). What to do when that data changes. Will the enforcer know of this change and tell the signer engine to XFR again and sign the new data? Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklrBZwACgkQ4nZCKsdOncUWoACfTTfigiF/dgbfP4INyfup+etV EPQAni0XXs1kCTbsg3+paSO3t4EbGX+S =aPAp -----END PGP SIGNATURE----- From jad at jadickinson.co.uk Mon Jan 12 11:05:54 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 12 Jan 2009 11:05:54 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <496B059F.5060100@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> <496B059F.5060100@NLnetLabs.nl> Message-ID: <0C8EACE8-713A-4341-9067-F87C757B60D0@jadickinson.co.uk> On 12 Jan 2009, at 08:55, Jelte Jansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Dickinson wrote: >> >> As promised here are my thoughts. This document is by no means >> complete >> and is only intended to reflect my understanding of what we are >> doing. >> Therefore, it will need some discussion :) >> > > just to beat the meeting and give us something to think about; > > what i'm missing from this document is where the actual content of the > zones lives. The doc seems to suggest that is is 'xfr upon need'; when > some signing of a zone needs to be done; the contents are fetched. > This > is not as i had understood (rather, i thought the whole system was > to be > either an actual master or an 'active' slave to another master; > keeping > the zone data synced as much as possible). > > What to do when that data changes. Will the enforcer know of this > change > and tell the signer engine to XFR again and sign the new data? I agree, we need to think about this. I see the system have having several adapters between the zone data and the signer engine. One of these would be as you suggest - an adapter that makes the signer appear to be a DNS server. In that case we need to think about where state would be kept and what the relationship is between the enforcer and the signer engine. John From jad at jadickinson.co.uk Mon Jan 12 16:49:30 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Mon, 12 Jan 2009 16:49:30 +0000 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B90411997186466D2@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> <69830D4127201D4EBD146B90411997186466D2@EXCHANGE.office.nic.se> Message-ID: <37685BC2-8DDA-4A11-900A-4E8251DB4544@jadickinson.co.uk> On 8 Jan 2009, at 13:41, Rickard Bondesson wrote: > >> I agree this should only be done if it is a question of >> supporting the correct attributes or something simple. Adding >> certs or symmetric keys is too much. I did try getting the >> opensc engine to talk to softHSM and it kept complaining >> about things (they seemed minor) but I didn't note down what >> they were - I will try again and post a summary. > > Ohh. Bug reports are always nice :) Well I really like softHSM - it is so easy to use and I really like the fact that it sort of creates users every time you use a different pin. - So simple :) How about a debug mode where softHSM logs all the pkcs11 calls to a file (maybe something simple like if you link to a version of the lib called libsofthsm-DEBUG.so. (I am thinking of the debug mode of a AEP Keyper where it logs if you access it via a host name of HSML instead of HSM.) These are my notes on trying to use it with a pkcs11 engine from opensc: #latest softHSM from svn on ubuntu #install Botan cd softHSM ./configure --prefix=/opt/softHSM make make install cd libp11-0.2.4 ./configure make sudo make install cd engine_pkcs11-0.1.5 ./configure make sudo make install # clean up cd rm -rf .softHSM/ # Access the softHSM pkcs11-tool --module=/opt/softHSM/lib/libsofthsm.so -L Available slots: Slot 1 SoftHSM token label: SoftHSM token manuf: SoftHSM token model: SoftHSM token flags: rng, login required, PIN initialized, token initialized serial num : 1 # Create a key pkcs11-tool --module=/opt/softHSM/lib/libsofthsm.so -k --key-type rsa: 1024 -l -p 12345678 Key pair generated: Private Key Object; RSA label: 090109122259177677 ID: 303930313039313232323539313737363737 Usage: decrypt, sign, unwrap Public Key Object; RSA 1024 bits label: 090109122259177677 ID: 303930313039313232323539313737363737 Usage: encrypt, verify, wrap # List objects pkcs11-tool --module=/opt/softHSM/lib/libsofthsm.so -O -l -p 12345678 Public Key Object; RSA 1024 bits label: 090109122259177677 ID: 303930313039313232323539313737363737 Usage: encrypt, verify, wrap Private Key Object; RSA label: 090109122259177677 ID: 303930313039313232323539313737363737 Usage: decrypt, sign, unwrap #Test with openssl speed # Create a openssl conf file /etc/ssl/openssl.cnf that looks like this: openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/local/lib/engines/engine_pkcs11.so MODULE_PATH = /opt/softHSM/lib/libsofthsm.so PIN = 12345678 init = 0 [req] distinguished_name = req_distinguished_name [req_distinguished_name] #end /etc/ssl/openssl.cnf #then try running it jad at test1:~$ openssl speed -engine pkcs11 unable to load module /opt/softHSM/lib/libsofthsm.so can't use that engine 14170:error:80001007:Vendor defined:PKCS11_CTX_load:Invalid arguments:p11_load.c:74: 14170:error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed:eng_table.c:161: As you can see the problem seems to be with the opensc libp11. Line 74 appears to be checking for errors resulting from calling C_Initialize. I tried commenting out line 74 to force it to ignore the error and it continues but comes up with a similar error later. John From Rickard.Bondesson at iis.se Tue Jan 13 07:59:01 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Tue, 13 Jan 2009 08:59:01 +0100 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <37685BC2-8DDA-4A11-900A-4E8251DB4544@jadickinson.co.uk> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> <69830D4127201D4EBD146B90411997186466D2@EXCHANGE.office.nic.se> <37685BC2-8DDA-4A11-900A-4E8251DB4544@jadickinson.co.uk> Message-ID: <69830D4127201D4EBD146B904119971864680E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Well I really like softHSM - it is so easy to use and I > really like the fact that it sort of creates users every time > you use a different pin. - So simple :) :) > How about a debug mode where softHSM logs all the pkcs11 > calls to a file (maybe something simple like if you link to a > version of the lib called libsofthsm-DEBUG.so. (I am thinking > of the debug mode of a AEP Keyper where it logs if you access > it via a host name of HSML instead of HSM.) I will put it in my todo list. > These are my notes on trying to use it with a pkcs11 engine > from opensc: I will have a look at this. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSWxJxeCjgaNTdVjaAQiFSwf9G+WTQc20qd7atVM1lQDExDFem7bqEbrf +ZWserBxrpFGK2YQRhyHqzXzDg2yvREXm6uMvwh2eaYwXCdTBSwDjZCCCI2udIde dUAvwlTKLK9TXlOC3PT7gEbqRCbEjg5Pe7K1Fep69WRqENDdO3ugfXxt+sqzscQd oFUPEKqXMSRQv3F0RkqlmVePnRxPoKynYl3YFH/XIM/xgWUuk+dvbslYLkNs462t vxrYpDj4ZWuowqtnAPog3+7uf4GWTJKyCIGLBBMnp82JWRwm0GzZrmhlRYD5ltUc FBKfYmxsyD4q2NYIwzysqMc+AjKntM4rNFhOz1P5TeQeSQkFcs/NcA== =dI1i -----END PGP SIGNATURE----- From roy at nominet.org.uk Tue Jan 13 14:40:29 2009 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 13 Jan 2009 15:40:29 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management Message-ID: OpenDNSSECers, When I took the lead to manage this project, I had the assumption that most of the architecture design was done, and what needed to follow was a simple implementation of the parts. My view was that this would be done in two phases. The first phase was a simple proof of concept, with mostly existing tools. The second phase is a production version. The proof of concept is simply a nameserver running as slave for the incoming unsigned zone, and as a master for the outgoing signed zone. The magic that causes the flip from unsigned to signed would be a regular running script that consults a database for the proper crypto-related data. I stand corrected. The necessity for IXFR, and the complexity that comes with it, renders the proof of concept completely useless for the production version. This became clear during the discussions at NLNetLabs last month. To be clear: I still want the proof of concept (PoC) version, albeit without IXFR. However, due to a busy agenda, and the unforeseen amount of work for this project, I'm handing projectmanagement over to Rickard Bondesson. Thanks guys, Roy From jad at jadickinson.co.uk Tue Jan 13 15:13:03 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Tue, 13 Jan 2009 15:13:03 +0000 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: On 13 Jan 2009, at 14:40, Roy Arends wrote: > OpenDNSSECers, > > When I took the lead to manage this project, I had the assumption that > most of the architecture design was done, and what needed to follow > was a > simple implementation of the parts. My view was that this would be > done in > two phases. The first phase was a simple proof of concept, with mostly > existing tools. The second phase is a production version. That's what I understood as well. > The proof of concept is simply a nameserver running as slave for the > incoming unsigned zone, and as a master for the outgoing signed > zone. The > magic that causes the flip from unsigned to signed would be a regular > running script that consults a database for the proper crypto-related > data. > > I stand corrected. > > The necessity for IXFR, and the complexity that comes with it, > renders the > proof of concept completely useless for the production version. This > became clear during the discussions at NLNetLabs last month. > > To be clear: I still want the proof of concept (PoC) version, albeit > without IXFR. Sorry, I don't understand now what the PoC is going to be. Something like what is on the wiki or a "...nameserver running as slave for the incoming unsigned zone, and as a master for the outgoing signed zone."? I know the nameserver version is something that we want, but I never realized that was what we were building as a PoC. In my mind the PoC was more for investigating how the bits would hang together, what data KASP would contain and what algorithms are needed for manipulating the KASP data and turning that in to signing operations. The nameserver version would evolve from that and reuse the technology and ideas developed by building the PoC. Regarding the nameserver version - I did a bit of thinking about that last year and came to the conclusion that it would be better to start with a nameserver and add signing than to start with a signer and add most of a nameserver to it. I came up with the following vague idea (the may be mis-understandings about how NSD works so feel free to put me right): NSD already has the ability to fork a process to perform XFR. This process uses IPC to signal to the parent that new zone data needs reloading. How about adding a signer process to NSD and re-directing the IPC so that it goes to the signer and once any signatures are added a signal is sent to parent to trigger the reload. NSD also has the necessary timers needed to trigger refreshes of the zone. presumably these could be used to trigger re-signings and key rollover as well. This signer process might well use KASP in order to figure out what to do and when. Thus it would evolve from the PoC of OpenDNSSEC. Are you or Stephen going to be calling into the meeting tomorrow? John From Stephen.Morris at nominet.org.uk Tue Jan 13 18:28:21 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 13 Jan 2009 18:28:21 +0000 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: Message-ID: jad at jadickinson.co.uk wrote on 13/01/2009 15:13:03: > > OpenDNSSECers, > > > > When I took the lead to manage this project, I had the assumption that > > most of the architecture design was done, and what needed to follow > > was a > > simple implementation of the parts. My view was that this would be > > done in > > two phases. The first phase was a simple proof of concept, with mostly > > existing tools. The second phase is a production version. > > That's what I understood as well. There seems to be some confusion as to what is being produced, so I think Rickard's first job is to sort that out :-) However, aren't we really after two configurations? Configuration A Master server --(unsigned zone via AXFR/IXFR)--> OpenDNSSEC --(signed zone via AXFR/IXFR)--> Slave server Configuration B Unsigned zone file ----> OpenDNSSEC ----> Signed zone file (and automatic loading into nameserver) The first configuration is best suited to TLDs and ISPs that manage large DNS installations, whereas the second would be ideal for companies that manage a single zone with few names that changes relatively infrequently. In both cases, OpenDNSSEC is doing the same job - signing zones and managing keys. As OpenDNSSEC is targeted at all users, I think that we should aim to build something that will handle both configurations. Most of the core key management and scheduling code (but not the signing code) will be common to both models, but IMHO the second will be easier to program and may be best for an initial implementation. > Are you or Stephen going to be calling into the meeting tomorrow? I aim to be there. Stephen From jakob at kirei.se Tue Jan 13 22:56:53 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 13 Jan 2009 23:56:53 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <4967534A.4080202@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl><494A6B19.3080005@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646689@EXCHANGE.office.nic.se> <080E6B2E-7530-45F6-8912-50225CC87862@jadickinson.co.uk> <4965E41B.60305@NLnetLabs.nl> <8EA917BF-AFBF-4EBF-AFCB-1A68EC3CB6F4@jadickinson.co.uk> <69830D4127201D4EBD146B9041199718646722@EXCHANGE.office.nic.se> <4967534A.4080202@NLnetLabs.nl> Message-ID: On 9 jan 2009, at 14.38, Jelte Jansen wrote: > Wednesday 14:00 CET is fine with me > > I've set up a conference room at > > sip:conference at NLnetLabs.nl I'll try to join, but tuesdays and wednesdays I'm at home with my son so it might not be possible. jakob From jelte at NLnetLabs.nl Tue Jan 13 23:17:33 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 14 Jan 2009 00:17:33 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <496D210D.9000904@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roy Arends wrote: > OpenDNSSECers, > > When I took the lead to manage this project, I had the assumption that > most of the architecture design was done, and what needed to follow was a > simple implementation of the parts. My view was that this would be done in > two phases. The first phase was a simple proof of concept, with mostly > existing tools. The second phase is a production version. > huh > > The necessity for IXFR, and the complexity that comes with it, renders the > proof of concept completely useless for the production version. This > became clear during the discussions at NLNetLabs last month. > Actually, it was already at the IETF, but that's probably besides the point. > > However, due to a busy agenda, and the unforeseen amount of work for this > project, I'm handing projectmanagement over to Rickard Bondesson. > Well, this is certainly unexpected. Rickard, good luck. Roy, will you still be involved? content-related responses coming up in replies to the other messages in this thread. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltIQkACgkQ4nZCKsdOncXEjACffrX3/WpHLJov4opqnELsfD/1 k68An2KIjP4IBBj3cYBef+QkQBPXSBqN =XUJD -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Tue Jan 13 23:21:06 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 14 Jan 2009 00:21:06 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <496D21E2.1060706@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Dickinson wrote: > > On 13 Jan 2009, at 14:40, Roy Arends wrote: > >> OpenDNSSECers, >> >> When I took the lead to manage this project, I had the assumption that >> most of the architecture design was done, and what needed to follow was a >> simple implementation of the parts. My view was that this would be >> done in >> two phases. The first phase was a simple proof of concept, with mostly >> existing tools. The second phase is a production version. > > That's what I understood as well. > Initially, me too, and that we (labs) were just going to make an rrset-signer that talks pkcs. But the earlier jabber meetings showed that there was still a lot more to work out. > > Sorry, I don't understand now what the PoC is going to be. Something > like what is on the wiki or a "...nameserver running as slave for the > incoming unsigned zone, and as a master for the outgoing signed zone."? > > I know the nameserver version is something that we want, but I never > realized that was what we were building as a PoC. In my mind the PoC was > more for investigating how the bits would hang together, what data KASP > would contain and what algorithms are needed for manipulating the KASP > data and turning that in to signing operations. > That's already different from the approach taken in the diagram on the wiki... > Regarding the nameserver version - I did a bit of thinking about that > last year and came to the conclusion that it would be better to start > with a nameserver and add signing than to start with a signer and add > most of a nameserver to it. I came up with the following vague idea (the > may be mis-understandings about how NSD works so feel free to put me > right): > > NSD already has the ability to fork a process to perform XFR. This > process uses IPC to signal to the parent that new zone data needs > reloading. How about adding a signer process to NSD and re-directing the > IPC so that it goes to the signer and once any signatures are added a > signal is sent to parent to trigger the reload. NSD also has the > necessary timers needed to trigger refreshes of the zone. presumably > these could be used to trigger re-signings and key rollover as well. > This signer process might well use KASP in order to figure out what to > do and when. Thus it would evolve from the PoC of OpenDNSSEC. > Actually, there is already a version of NSD that does automatic zone (re)signing. It's the one modified by secure64. But I don't think NSD is a good starting point. We don't need something that's optimized on fast individual answers, we need something that is optimized to coherent changes both from within (automatic signing) and outside (zone updates and key changes) to individual zones. This is even without IXFR. But if we're looking ahead; NSD is *really* not suited for serving IXFR. (yes i am approaching this from the nameserver point of view, not the keys pov) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltIeIACgkQ4nZCKsdOncUUXgCfc/tcxURLOCBPq+757miF6yDp JMsAmwSfwuTXYMlfnNnTgVX5+GR816W+ =Z3wS -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Tue Jan 13 23:24:33 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 14 Jan 2009 00:24:33 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <496D22B1.7090509@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen.Morris at nominet.org.uk wrote: > jad at jadickinson.co.uk wrote on 13/01/2009 15:13:03: > >>> When I took the lead to manage this project, I had the assumption that >>> most of the architecture design was done, and what needed to follow >>> was a >>> simple implementation of the parts. BTW, Roy, I finally understand your optimistic view on the 'deadline' dates... >>> My view was that this would be >>> done in >>> two phases. The first phase was a simple proof of concept, with mostly >>> existing tools. The second phase is a production version. >> That's what I understood as well. > > There seems to be some confusion as to what is being produced, so I think Yes. But not even so much on the place of the system as a whole, but more on the subsystems and where what 'intelligence' lies, imho. Both seem to be different in everybody's view. > Rickard's first job is to sort that out :-) > Indeed. Then a project plan and some actual milestones would be nice asap. I hope we can get there tomorrow, but I don't think we will be able to in the span of one conference call. In fact, last year, Roy already proposed to arrange a face 2 face meetup. I guess his arrangements will now be out of the picture but I would like to ask whether we can do this. Fast. > However, aren't we really after two configurations? > > Configuration A > Master server --(unsigned zone via AXFR/IXFR)--> OpenDNSSEC --(signed zone > via AXFR/IXFR)--> Slave server > > Configuration B > Unsigned zone file ----> OpenDNSSEC ----> Signed zone file (and automatic > loading into nameserver) > The left part of both A and B isn't really different from the viewpoint of OpenDNSSEC. Configuration B can be done with just about any signing tool currently available. Technically, it's probably what we're all already running for our own zones... > The first configuration is best suited to TLDs and ISPs that manage large > DNS installations, whereas the second would be ideal for companies that > manage a single zone with few names that changes relatively infrequently. > In both cases, OpenDNSSEC is doing the same job - signing zones and > managing keys. As OpenDNSSEC is targeted at all users, I think that we > should aim to build something that will handle both configurations. Most > of the core key management and scheduling code (but not the signing code) > will be common to both models, but IMHO the second will be easier to > program and may be best for an initial implementation. > But those aren't the biggest challenges imho. It's keeping track of what data needs to be signed without walking through your entire collection of zones and all their records. In the case of TLD's and ISP's that is just not feasible. > >> Are you or Stephen going to be calling into the meeting tomorrow? > > I aim to be there. > Good. Talk to you guys tomorrow. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltIrEACgkQ4nZCKsdOncWvJQCfUWdRwafcY2SLOZ2nZrkCBgYe bSwAoJMebzFhDPeUda6GeMY/2GODtKxO =iLJN -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Tue Jan 13 23:31:39 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 00:31:39 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <1006BC6B-A5F5-4906-8070-5CBD7204FF5B@NLnetLabs.nl> This got stuck in the moderators queue... resend without picture On Jan 13, 2009, at 5:59 PM, Olaf Kolkman wrote: > > On Jan 13, 2009, at 4:13 PM, John Dickinson wrote: > >> >> Regarding the nameserver version - I did a bit of thinking about >> that last year and came to the conclusion that it would be better >> to start with a nameserver and add signing than to start with a >> signer and add most of a nameserver to it. I came up with the >> following vague idea (the may be mis-understandings about how NSD >> works so feel free to put me right): > > > > John, > > As an aside... > > Below is a picture that most of the project people have been > involved in have seen and that has developed separately from > OpenDNSSEC. The picture is a an architecture for what I call > "Masterdont" > > It contains all intelligence about the concept of zones and would > for instance know when data for a specific zone was changed, what > the state for IXFR or incoming AXFR is. > > When talking to opendnssec folk it appeared to me that the > opendnssec architecture could naturally hook into this architecture. > Basically by having the KASP API and the Crypto API live on the > bottom of the kernel in this picture. > > In all honesty I am looking at the developments from a distance but > I have the feeling that most of the uncertainty and risk of this > project is in the "Zone Intelligence" that is needed. I have not > been convinced that we do not need parts of this "Masterdont Kernel" > to do the implementation: A clear understanding of when zones are > subject to change and a state machine that understands that it > received data from the KASP or understands that it needs to poll the > KASP so that it can schedule generations of (a subset of) a zones > signatures. > > If you want to follow a POC that does not do IXFR then I do not see > a fundamental difference with an implementation that is just a KASP > aware signer that takes in an (un)signed zone file and spits out a > (re)signed zonefile based on existing policy. Pulling in a zonefile > over DNS and spitting it out over DNS is just window dressing. At > the moment you want to do more and be more flexible you will need to > understand all the various states a zone can be in. > > I will try to be on the call tomorrow and will try to shut up. > > > --Olaf > > > > > > > > > > > > ----------------------------------------------------------- > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam > > NB: The street at which our offices are located has been > renamed to the above. > > > > ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From olaf at NLnetLabs.nl Tue Jan 13 23:35:36 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 00:35:36 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <1006BC6B-A5F5-4906-8070-5CBD7204FF5B@NLnetLabs.nl> References: <1006BC6B-A5F5-4906-8070-5CBD7204FF5B@NLnetLabs.nl> Message-ID: On Jan 14, 2009, at 12:31 AM, Olaf Kolkman wrote: > > This got stuck in the moderators queue... resend without picture For picture see: www.secret-wg.org/MasterDont.png Sleep well.. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From olaf at NLnetLabs.nl Tue Jan 13 16:59:54 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 13 Jan 2009 17:59:54 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: On Jan 13, 2009, at 4:13 PM, John Dickinson wrote: > > Regarding the nameserver version - I did a bit of thinking about > that last year and came to the conclusion that it would be better to > start with a nameserver and add signing than to start with a signer > and add most of a nameserver to it. I came up with the following > vague idea (the may be mis-understandings about how NSD works so > feel free to put me right): John, As an aside... Below is a picture that most of the project people have been involved in have seen and that has developed separately from OpenDNSSEC. The picture is a an architecture for what I call "Masterdont" It contains all intelligence about the concept of zones and would for instance know when data for a specific zone was changed, what the state for IXFR or incoming AXFR is. When talking to opendnssec folk it appeared to me that the opendnssec architecture could naturally hook into this architecture. Basically by having the KASP API and the Crypto API live on the bottom of the kernel in this picture. In all honesty I am looking at the developments from a distance but I have the feeling that most of the uncertainty and risk of this project is in the "Zone Intelligence" that is needed. I have not been convinced that we do not need parts of this "Masterdont Kernel" to do the implementation: A clear understanding of when zones are subject to change and a state machine that understands that it received data from the KASP or understands that it needs to poll the KASP so that it can schedule generations of (a subset of) a zones signatures. If you want to follow a POC that does not do IXFR then I do not see a fundamental difference with an implementation that is just a KASP aware signer that takes in an (un)signed zone file and spits out a (re)signed zonefile based on existing policy. Pulling in a zonefile over DNS and spitting it out over DNS is just window dressing. At the moment you want to do more and be more flexible you will need to understand all the various states a zone can be in. I will try to be on the call tomorrow and will try to shut up. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled(0884C51E).png Type: image/png Size: 177630 bytes Desc: not available URL: -------------- next part -------------- ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From rick at openfortress.nl Wed Jan 14 07:25:16 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 14 Jan 2009 07:25:16 +0000 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <20090114072516.GA13601@phantom.vanrein.org> Hello, I hope you are not leaving us, Roy. I am also looking forward to having the beer we planned to have here in Enschede. > To be clear: I still want the proof of concept (PoC) version, albeit > without IXFR. I also think the smallest working version is the best place to start. But it may also be good to already be aware of future extension needs, so the structures will be prepared. > However, due to a busy agenda, and the unforeseen amount of work for this > project, I'm handing projectmanagement over to Rickard Bondesson. This is not as democratic as I had expected this to be. Actually, I wonder if anyone on this list is an optimal choice of a project manager. Being technicians, we all have a tendency to dive into details, and I have consistently seen that on the list. It is our thing! But when I think of a project manager I imagine someone to monitor the structure, while staying at an arm's length of detail. Issues that play in the mind of a project managers are not key stores or zone wire formats but ought to deal with cost, time, and scope. I think we could use someone like that. http://en.wikipedia.org/wiki/Project_manager http://en.wikipedia.org/wiki/Project_management Rickard, note that this is not about you as a person. Roy, note that I like that you are assigning a replacement instead of dropping the whole thing. I propose to ask Roy or Rickard to act as an interim project manager, and in the mean time look in our organisations if we can bind in someone with a more structural style of monitoring, preferrably a senior engineer who converted into a project manager. As much as I value actual coding and not just theorising about a would-be product, I think we are in urgent need of more structural documentation, in the form of requirements, designs and milestones/timelines. I for one need more overview over the project than what I've collected up till now. Just starting to code doesn't honour the importance of OpenDNSSEC. Cheers, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From matthijs at NLnetLabs.nl Wed Jan 14 08:16:04 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 14 Jan 2009 09:16:04 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <496D22B1.7090509@NLnetLabs.nl> References: <496D22B1.7090509@NLnetLabs.nl> Message-ID: <496D9F44.5000402@nlnetlabs.nl> > Yes. But not even so much on the place of the system as a whole, but more on the > subsystems and where what 'intelligence' lies, imho. Both seem to be different > in everybody's view. +1. We all seem to agree that an unsigned zone comes in [in any form], is adapted to a signed zone that can be served [full or incremental] to the actual slaves. However, there seems to be little consistency in how this should be achieved, imo. >> However, aren't we really after two configurations? > >> Configuration A >> Master server --(unsigned zone via AXFR/IXFR)--> OpenDNSSEC --(signed zone >> via AXFR/IXFR)--> Slave server > >> Configuration B >> Unsigned zone file -,---> OpenDNSSEC ----> Signed zone file (and automatic >> loading into nameserver) I thought the configuration always ended in a signed zone that can be served to the slaves, incremental or full. >> The first configuration is best suited to TLDs and ISPs that manage large >> DNS installations, whereas the second would be ideal for companies that >> manage a single zone with few names that changes relatively infrequently. >> In both cases, OpenDNSSEC is doing the same job - signing zones and >> managing keys. As OpenDNSSEC is targeted at all users, I think that we >> should aim to build something that will handle both configurations. Most >> of the core key management and scheduling code (but not the signing code) >> will be common to both models, but IMHO the second will be easier to >> program and may be best for an initial implementation. > > > But those aren't the biggest challenges imho. It's keeping track of what data > needs to be signed without walking through your entire collection of zones and > all their records. In the case of TLD's and ISP's that is just not feasible. I think both scheduling and tracking are challenging. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From matthijs at NLnetLabs.nl Wed Jan 14 08:21:32 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 14 Jan 2009 09:21:32 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <496D21E2.1060706@NLnetLabs.nl> References: <496D21E2.1060706@NLnetLabs.nl> Message-ID: <496DA08C.8090008@nlnetlabs.nl> >> Regarding the nameserver version - I did a bit of thinking about that >> last year and came to the conclusion that it would be better to start >> with a nameserver and add signing than to start with a signer and add >> most of a nameserver to it. I came up with the following vague idea (the >> may be mis-understandings about how NSD works so feel free to put me >> right): > >> NSD already has the ability to fork a process to perform XFR. This >> process uses IPC to signal to the parent that new zone data needs >> reloading. How about adding a signer process to NSD and re-directing the >> IPC so that it goes to the signer and once any signatures are added a >> signal is sent to parent to trigger the reload. NSD also has the >> necessary timers needed to trigger refreshes of the zone. presumably >> these could be used to trigger re-signings and key rollover as well. >> This signer process might well use KASP in order to figure out what to >> do and when. Thus it would evolve from the PoC of OpenDNSSEC. > > > Actually, there is already a version of NSD that does automatic zone > (re)signing. It's the one modified by secure64. But I don't think NSD is a good > starting point. We don't need something that's optimized on fast individual > answers, we need something that is optimized to coherent changes both from > within (automatic signing) and outside (zone updates and key changes) to > individual zones. > > This is even without IXFR. But if we're looking ahead; NSD is *really* not > suited for serving IXFR. +1 for both reasons. However, of course, this should not prevent us to copy some useful parts. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From rick at openfortress.nl Wed Jan 14 09:11:29 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 14 Jan 2009 09:11:29 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> Message-ID: <20090114091129.GB13601@phantom.vanrein.org> Hello, Thanks to John for writing down his thoughts and understanding of the OpenDNSSEC project so far. We need people who document and get us talking about the design, instead of only detail. This doc certainly gets me going! Here are points of feedback on what we currently have. >> POLICIES What I am missing in your document as well as in anything I've seen so far, is some form of requirements. A quick word about importing and exporting IXFR/AXFR is about all I've seen. Concretely, it is not clear who put in the policies and what they are meant for. I've come in later than others, and have hitherto assumed that I must've missed it, but there's nothing written down on it, is there? So now that I'm faced with an ER diagram I'm starting to wonder what all these blocks with intuitive names and their associations mean. I think pinning down the semantics is much more important than settling an ER diagram. Who introduced policies, and what is s/he trying to achieve with it? Do we need explicitly modelled policies with per-domain settings, or are these the usual global settings that we normally put in a config file to influence local choices at pivotal points in our code, or is it even possible to derive them from RFCs and hardcode them into the software? I wonder if putting in policies from the start is a true need for a first release of OpenDNSSEC. >> COMPONENT IDENTIFICATION We have introduced a number of components, but once again it is not clear to me what their exact task is. Judging from the brevity of John's descriptions, I am not the only one who is looking for more information. The names surely are not give-aways for their intentions (nor would that suffice). A way to pin down the components' functions could be: 1. Brainstorm to identify responsibilities that OpenDNSSEC should have 2. Allocate responsibilities to components 3. In case of mismatches during 2, introduce/change/remove components 4. Assign coding such responsibilities to parties involved in OpenDNSSEC Given that responsibilities are distributed, hopefully it suffices to draw up scenarios or use cases for all normal *and* abnormal use, and then to define an API and start coding it. >> OBJECT IDENTIFICATION When concerned with objects that need to be stored, we could (and probably should) be guided a bit more by the concepts that we are trying to capture. A "dnsseckey" may be clear from the RFCs but it would be helpful to know when it is created, read, updated, deleted and who does so. New objects such as "adapters" need a lot more descriptive information to settle their semantics like the RFCs do for "dnsseckeys". When identifying concepts, do not overlook associations/relations between data objects. They have cardinality, but also a meaning. A name is the least to add as a minor hint towards the intentions of a relationship between data objects. This is not me being picky, but having experienced over and over again that a database schema simply isn't sufficient documentation to get a heterogeneous group of more than one person in line with the ideas behind the scheme. Most of us will have peeked in a database that someone else created without other documentation than what will be surrendered by the database, only to find that a lot of assumptions are called for to work on it. >> CENTRAL/MANAGEMENT COMPONENTS A design should be very cautious about introducing a "manager" or "controller" block in a design. Such blocks tend to contain all intelligence, leaving the rest as dumb data-servicing elements. This means that the attempt to analyse the problem and come up with smaller blocks has failed. One ends up with a molog of a block. Think of governments and you'll see my point: Do not centralise any responsibility if you can avoid it. In the current design, I see a few blocks that seem to want to coordinate: Enforcer, Signer Engine, and perhaps KASP too. If one coordinator is a problem, then multiple are worse. I do not think that style of design is helpful in pinning down the responsibilities to be picked up by the parties involved in OpenDNSSEC. I think these problems can be avoided, but from another viewpoint than taken by this design. For that reason, I've made another model and description, more shaped like a dataflow, through which DNS updates ripple from input or an internal event all the way to the output, where they represent a signed zone. It has no unit in central control of anything; responsibilities are split into smaller parts and spread over components, which end up being doable implementation efforts. This other view on OpenDNSSEC is attached to this email, and yes, you are *quite* welcome to publicly beat me up if it is faulty in any way. It certainly makes choices in the realms of concurrency, scheduling and the overall collaboration of OpenDNSSEC parts that are new, and thus open to debate. I'd have released it after a bit more discussion with NLNet Labs if it weren't for the conference call later this day. >> NO GUESSWORK We are building a secure system, and anything that makes us guess what another guy or gal means is a potential hole in the eventual software. So even if I'm writing not because I'm picky but because I'm confused, I also have reasons to be picky on the software that we build We need to properly document our thoughts, and follow the proper tools set out for these tasks. I want to vent my gut feeling is that nobody knows where we are heading, and that we should get this train back on the rails -- preferrably on bars that run in parallel. If I'm the only one to think so, be sure to tell me. But I'm starting to suspect I might be phrasing what others feel as well. I hope the attached designs create so much concrete handle bars that we can start debating about the structure of OpenDNSSEC and distribute responsibilities sometime soon. I sincerely hope this helps. Warm regards, Rick van Rein OpenFortress Digital signatures for SURFnet -------------- next part -------------- A non-text attachment was scrubbed... Name: opendnssec.pdf Type: application/pdf Size: 18007 bytes Desc: dataflow diagram URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flow-descr.pdf Type: application/pdf Size: 102580 bytes Desc: descriptive document URL: -------------- next part -------------- --- ./flow-descr.rst 2009/01/14 08:05:08 1.1 +++ ./flow-descr.rst 2009/01/14 08:18:06 @@ -16,7 +16,7 @@ We need a few clear concepts to guide us through the incredibly versatile possibilities of concurrency. If not, we could easily drown and be left -with a scheduling problem that is too broad to be effectivel implemented. +with a scheduling problem that is too broad to be effectively implemented. Below, the following principles are proposed as guidelines to keep the concurrency model simple yet flexible: @@ -27,7 +27,7 @@ * Serialisable domain updates * State-of-the-art DNS queries -These concepts help to avoid rece conditions, and the absense of directed +These concepts help to avoid race conditions, and the absense of directed cycles (that is, cycles found when following arrows in their pointing direction) makes it possible to be sure that there will be no deadlock either. @@ -45,7 +45,7 @@ of a resource record, followed by new record data (or nothing if there are no new contents). These "Diff" records are conceptually similar to an IXFR, although it is likely that a realistic IXFR will be split into smaller -blocks, each of which would separately be treated an RRset to be signed. +blocks, each of which would separately be treated as an RRset to be signed. The separation of IXFR into minimalistic "Diff" records (and differencing an AXFR to obtain similarly small "Diff" records) is helpful in enabling @@ -60,7 +60,7 @@ A queue is a conceptually straightforward synchronisation construct. Its principal operation comes down to a first-in, first-out structure. In reality though, a queue could optimise by sending out high-priority -events before normal-priority ones. This could be used to avance +events before normal-priority ones. This could be used to advance emergency operations like emergency key rollover. Queues should adhere to the principle of domain serialisability, @@ -79,7 +79,7 @@ not be a need to actually lock anything. Also, an implementation might do everything before Q2 in one process -(probably using ``select()`` to be able to wait for I/O or alerts) then +(probably using ``select()`` to wait for I/O or alerts) then there is effectively no need to lock the writing side of Q2 at all, let alone compete. @@ -160,17 +160,42 @@ locked -- the latter being subject to change. For example, if the step "re-list all RR" needs to query for all records -in a domain, it would as Q2, who could either find a "Diff" that answers +in a domain, it would ask Q2, who could either find a "Diff" that answers the query, or pass it on to Q3, Q4 and so on until zoneDB. If the same name occurs in Q2 and zoneDB, the "Diff" in Q2 prevails. If a "Diff" exists in Q3 and Q4 covering the same DNS request, the version in Q3 is delivered back to the inquiring process. -NSEC(3): Mathematics of ordering +Structure: Timing and scheduling ================================ -DNS data for signing comprises of resource records as well as holes +DNS introduces timing requirements in the form of TTL and SOA parameters. +DNSSEC adds even more such constraints. + +In essence, the adjoining schema does not take all these timing requirements +into account. Instead, the proposal is to look upon it as a generic +problem of *realtime scheduling*. + +Based on this view, it ought to be possible to infer a set of queries +that can be sent to the various blocks of the system to investigate how +much work is still in progress, how much is lying ahead (due to timer-based +events) and at what time each change should be triggered. + +I expect a generic realtime scheduler to solve this problem for us, and +that we will only have to supply it with timing details and the proper set +of priorities. Low priorities for user-initiated changes (IXFR from the +master), medium for emergency rollovers and medium to high for +time-scheduled operations. + +The realtime scheduler will be linked in with the processes that run, as +well as the ordering of queues. + + +Model: NSEC(3) and ordering +=========================== + +DNS data for signing comprises of resource records as well as *holes* between them. The holes need explicit handling because they will be signed just as well as resource records. @@ -184,11 +209,11 @@ Note that this is not likely to happen at all, since NSEC3 makes multiple passes with a single hash which is thought to be good. -But if it ever happens, it is best to resolve it withouth domain +But if it ever happens, it is best to resolve it without domain downtime, especially because such changes would probably apply to many domains at the same time. -Efficiency of NSEC3 chain rollover is an interesting concern if it +Efficiency of NSEC3 chain rollover is an important concern if it is indeed the case that multiple domains will want to do the same rollover at the same time. @@ -204,10 +229,10 @@ records; and ``R`` defines relations between elements of ``S``. The relation ``R`` can have a number of useful properties: -* ``R`` is tranisitively closed if for any ``(a,b)`` and ``(b,c)`` in ``R``, +* ``R`` is *transitively closed* if for any ``(a,b)`` and ``(b,c)`` in ``R``, their composition ``(a,c)`` is also part of ``R`` -* ``R`` is complete if for any pair of different values ``a`` and ``b`` in +* ``R`` is *complete* if for any pair of different values ``a`` and ``b`` in ``S``, either ``(a,b)`` or ``(b,a)`` is part of ``R`` If we use ``R`` to model the order in which NSEC or NSEC3 records are @@ -249,15 +274,15 @@ zones, notably TLDs. This means that it is probably best to create an order in one operation covering all records found in a domain. Later, when records are individually removed or added as a result of -"Diff" records, loose changes to the NSEC or NSEC3 order can be made -by way of cutting and joining holes as described above. +"Diff" records, small changes to the NSEC or NSEC3 order can be made +by way of cutting-up and joining holes as described above. -Explaining the diagram blocks -============================= +Description: Diagram blocks +=========================== -Following is a description from each non-trivial block in the diagram. +Following is a description for each block in the diagram. DNS from master --------------- @@ -269,21 +294,25 @@ --------- For incoming IXFR, it is good to know that the order in which data comes -in is reliable. If not, an AXFR should be requested instead and treated +in is correct. If not, an AXFR should be requested instead and treated by the "diff" process. -A sinlge IXFR may be split into multiple "Diff" records, each covering +A single IXFR may be split into multiple "Diff" records, each covering an RRset. This means that the "Diff" records are nice and small. -SOA/dom -------- +serial/dom +---------- Stores the latest accepted SOA serial number per domain. This may come from either IXFR or AXFR interactions with the master. -Note that SOA and its serial numbers need not be passed on in the rest +Note that SOA serial numbers need not be passed on in the rest of the OpenDNSSEC flow of "Diff" events. The last stages will add a -SOA value to match the version of the domain. +serial number to match the version of the domain. + +The reason that incoming and outgoing serial numbers are not coupled +is that, between two consecutive incoming numbers, OpenDNSSEC may have +to insert a version for its own reasons, for reasons like a key rollover. diff ---- @@ -313,7 +342,7 @@ KASP will trigger a Timeout for a DNSKEY under a zone, and trigger its replacement. -It is a matter of taste if the DNSKEY durability knowlede is located +It is a matter of taste if the DNSKEY durability knowledge is located in the KASP, or that the KASP is only the source of Timeouts at given moments. Since a HSM often contains a secure timer, it makes sense to assign the responsibility of timekeeping to the KASP. @@ -342,6 +371,11 @@ timeouts, namely those for introduction and those for removal of DNSKEY records. +This process also craetes a "Diff" record for a SOA to indicate a wish +to publish a zone's intermediate state. To get this, it simply requests +the state-of-the-art SOA record and creates a "Diff" that both removes +and creates that same SOA. Serial numbers are a matter of later concern. + KASP pubkeys ------------ @@ -358,7 +392,7 @@ create a new NSEC3 chain, a process similar to DNSKEY rollover can be initiated. The "Diff" submitted will also proceed in two phases; first, a new NSEC3PARAM will be added to the state-of-the-art NSEC3PARAM, and -second, the oldest NSEC3PARAM will be removed. +second, the older NSEC3PARAM will be removed. NSEC3 emerg ----------- @@ -373,6 +407,11 @@ their useful life. Note that NSEC3 and NSEC chains are created further down the workflow. +This process also craetes a "Diff" record for a SOA to indicate a wish +to publish a zone's intermediate state. To get this, it simply requests +the state-of-the-art SOA record and creates a "Diff" that both removes +and creates that same SOA. Serial numbers are a matter of later concern. + AND --- @@ -402,11 +441,20 @@ in the same atomic "Diff", reconstructs it. This is intended to trigger the signing processes downstream. +This process also craetes a "Diff" record for a SOA to indicate a wish +to publish a zone's intermediate state. This may be prudent to do after +partial updates, so that other processes can intervene and the domain +updates are split in separate IXFR records. To get this, it requests +the state-of-the-art SOA record and creates a "Diff" that both removes +and creates that same SOA. Serial numbers are a matter of later concern. + name*order storage ------------------ This database stores the ``(S,R)`` relations of DNS names and the -corresponding order or orders that are currently in use. +corresponding order or orders that are currently in use. If multiple +NSEC/NSEC3 chains are being built or used, multiple name*order relations +are stored for a single zone. add NSEC(3) ----------- @@ -422,7 +470,7 @@ for "name*order". As part of the same transaction, all NSEC3 records are supplied as "Diff" records on the process's output. -In general, when a RRset is changed by a "Diff" on the input (and that +In general, when an RRset is changed by a "Diff" on the input (and that includes NSEC3PARAM) the "name*order" storage and the NSEC and/or NSEC3 records are created to match: @@ -430,7 +478,7 @@ * If a record name is inserted, the hole in which it falls is cut in two. -* If a new record type is added to or removed from a name that existed +* If a new record type is added to or removed from a name that exists beforehand and afterwards, the set of RRtypes in any NSEC3 record is altered and a new NSEC3 record created. @@ -453,22 +501,24 @@ contained in it. This usually includes NSEC3 records as well as plain records. -It is this unit that creates new SOA records for outgoing domain names. -It has the freedom to pull in multiple "Diff" records for the same domain -if it can find them. It is probably smart to avoid collecting too much -in one stroke, to avoid loosing the OpenDNSSEC's responsiveness. On the -other hand, signing every RRset (or "Diff" record) separately may be -too fine a granularity for signing. Something practical could be found -somewhere halfway. +This step also creates a new SOA serial number for the newly signed +zone. It does this whenever it comes accross a SOA record, which it +sees as an indication that the zone should be published. + +The simplicity of the RRset signer mainly stems from the preparation +by the previously added NSEC(3) records and by the separation of +"Diff" messages into atomic RRset changes. + +The relative indpendency of the RRsets to be signed means that an +optimisation for parallel signing could be setup. Note that the +best way of doing this is probably to delegate such concurrency +to the KASP's privkey ops, that is, the signer engine. -Note: Combining "Diff" records for a domain could be a separate -processing step. - -SOA/dom -------- +serial/dom +---------- This is a database similar to its same-named compadre in the input processing -stage. It stores the SOA values added to the output records. +stage. It stores the SOA serial values added to the output records. zoneDB ------ @@ -476,6 +526,8 @@ This database stores the completely signed records for a zone. This database supports a number of operations, all of which are transactional: +* Collecting a new IXFR as a sequence of RRsets + * Inserting an additional "Diff" for a zone as an IXFR * Retrieving a zone's IXFR and AXFR data @@ -489,7 +541,7 @@ principles, possibly in combination, to achieve this effect: * When there is more IXFR data than AXFR data for a zone, any number of - IXFRs can be combined with the AXFR + the oldest IXFRs can be combined with the AXFR * When an IXFR is past its SOA-indicated lifetime, it can be combined with the AXFR @@ -507,6 +559,8 @@ Scenarios ========= -This section will show a number of scenario's or use cases rolling through -the workflow. It will end by detailing the interactions between the +This section shows a number of scenarios or use cases rolling through +the workflow. It ends by detailing the interactions between the DNS workflow module and the KASP module. + +**TODO** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From roy at nominet.org.uk Wed Jan 14 09:20:12 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 14 Jan 2009 10:20:12 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <20090114072516.GA13601@phantom.vanrein.org> References: <20090114072516.GA13601@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 01/14/2009 08:25:16 AM: > Hello, > > I hope you are not leaving us, Roy. I am also looking forward to having > the beer we planned to have here in Enschede. I'm not leaving. We'll do beer soon. > > However, due to a busy agenda, and the unforeseen amount of work for this > > project, I'm handing projectmanagement over to Rickard Bondesson. > > This is not as democratic as I had expected this to be. Rick, This project needs management, I lack time. Rickard Bondesson's SoftHSM part for OpenDNSSEC is mostly (if not completely) done. He consistently produced results for the SoftHSM part, while keeping an interest in the development of the OpenDNSSEC project, without getting into gory details. He is the obvious choice. This is not a democracy. There is no vote. Roy From olaf at NLnetLabs.nl Wed Jan 14 10:32:15 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 11:32:15 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <20090114091129.GB13601@phantom.vanrein.org> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> <20090114091129.GB13601@phantom.vanrein.org> Message-ID: <2CECD06D-870C-4AA5-AC4F-18F592CE6FFC@NLnetLabs.nl> Rick, Skimming your documents I understand that you focus on the atomic coherency of possibly small sets of data (a couple of RRsets). The immediate question that I have is how you take care of zone coherency. From a metalevel it is the operation on a zone that needs to be 'atomic'. I would need to be explained how you maintain that view within your design. --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From rick at openfortress.nl Wed Jan 14 10:42:08 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 14 Jan 2009 10:42:08 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <2CECD06D-870C-4AA5-AC4F-18F592CE6FFC@NLnetLabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> <20090114091129.GB13601@phantom.vanrein.org> <2CECD06D-870C-4AA5-AC4F-18F592CE6FFC@NLnetLabs.nl> Message-ID: <20090114104208.GA21731@phantom.vanrein.org> Olaf, > Skimming your documents I understand that you focus on the atomic > coherency of possibly small sets of data (a couple of RRsets). The > immediate question that I have is how you take care of zone coherency. The small (RRset size) changes that propagate through the dataflow end at the zoneDB -- at that place, I imagine collecting all RRsets under a zone until they are followed by a SOA. Then all up to then, including the SOA, is stored as an IXFR or AXFR into the zoneDB. This means that there is a transaction for each domain being signed, maintained upon entry in the zoneDB. Or in other words, data is being collected in a pre-publishing file and later moved into the publication area if zoneDB is implemented in files. > From a metalevel it is the operation on a zone that needs to be > 'atomic'. I would need to be explained how you maintain that view > within your design. 1a. Stuff comes in as an IXFR or AXFR, or 1b. Stuff is created in response to internal needs 2. Stuff is passed on as RRset-sized "Diff" messages, each atomic, with a SOA "Diff" closing a zone's changes 3. Stuff gets processed per RRset: NSEC(3) appended, SOA serial number inserted, RRSet signing 4. Stuff gets collected and only published when the trailing SOA drips in So the SOA record mirrors what "commit" does in a database. A new SOA record is needed on any change, as its serial number must be updated. And you'll never need more than one such change per zone update. So it can serve as the "end of transaction" marker. Hope this helps, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From Rickard.Bondesson at iis.se Wed Jan 14 10:49:12 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 14 Jan 2009 11:49:12 +0100 Subject: [Opendnssec-develop] 20080114 Meeting Agenda Message-ID: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The agenda is almost the same as the one by John. I have added a time schedule and question point number one. See below. Conference call arranged by Jelte: sip:conference at NLnetLabs.nl the pin number is 5227# If you don't have a sip phone or client available, the room should also be available at +31 20 7508314 extension 263 (just dial 263 when olaf's recorded voice starts talking) How about a Jabber channel? I can write minutes and email a summery. // Rickard - -------------------------- Agenda Time: 14:00 - 15:30 CET / 90 minutes 1. Project management (10 min) 1a. Who will be responsible? 1b. What responsibilities does this person have? 1c. Meetings? In real life? Jabber? Telephone? 2. Agree what the components are (System design) (35 min) 2a. Agree on the general system design 2b. Discuss any known contradictions on the wiki 2c. How do the components interface with each other in both the prototype and final systems 2d. Discuss technology to be used for each component 2e. Do we know the requirements for each component? 2f. Answer the question Matthijs asked in his email (see below) 3. Agree who is developing each component (6 min) 4. Discussion of the commitment needed for each component and available from each party. (6 min) 5. Brief update on the state of each component where possible (10 min) 6. Discuss and agree plan to move forward (10 min) 6a. Discuss timeline for whole project 6b. Decide on milestones for each component 6c. What about testing? 7. Decide on date of next meeting (3 min) 8. Agree actions (10 min) 8a. Who writes minutes 8b. Who is writing any documentation still needed 8c. Who updates the wiki based on this meeting 8d. Other... List of questions from Matthijs 1. From the opendnssec.org website, I assume that the Signer has to determine the inception and expiration times on signatures. It can determine this from the refresh interval. (Ok, not a real question:)) 2. What's the difference between zone resigning interval and signature refresh interval? Imho, they are the same, but described differently. 3. What is the priority of changing security parameters? For example, it could be that the signature validity period has changed. Does this need to be applied to all signatures directly, or are they applied to upcoming generated signatures only? 4. What is meant with signature jitter and clockskew? Does this affect the zone content? If so, in what way? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSW3DKOCjgaNTdVjaAQgXzAf9G4hS55qnY1YTXs4LqDGuZ9+vlBmQq/uK 2ayP+8LeOME54Wvi/jTw1Z7syeADk2Qybw671hPnj7U+DWcQgl59w+bPB0owsLgH rL5UQBz22lJ9PoVaS1gPOei8EgDmCxLtDwYC2Ew1EUBKNtBvCrkO47S8SvgqJ4zV xBUlNZ4s9D7llpabnAfStuHG+TaDA63pHgt1Qt5oCRoJkVxNWFZ8piCA8zqwOlyB EFt4cEv87RYxyBRGcsM5ULH8/OEahvpG7EqKDaanl/uL6AfY0aghzQpQrxoE67rR XxbH5C/FAumsIo67YRLL8woG3RkJFrZLZXcx4cET0x1t7QaUfdSAPA== =NdZZ -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Wed Jan 14 10:53:12 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 14 Jan 2009 11:53:12 +0100 Subject: [Opendnssec-develop] 20080114 Meeting Agenda In-Reply-To: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> Message-ID: <496DC418.5090403@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: > The agenda is almost the same as the one by John. I have added a time schedule and question point number one. See below. > i would suggest moving item 8a (who writes minutes) to 0a. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltxBgACgkQ4nZCKsdOncW7ZwCdHjnOtk+ZtXGMP3GaIfYw6+JO 7iMAn0enHyZFwN9nP3T0huAKMWDH1p1w =pXi6 -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Wed Jan 14 10:57:14 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 14 Jan 2009 11:57:14 +0100 Subject: [Opendnssec-develop] 20080114 Meeting Agenda In-Reply-To: <496DC418.5090403@NLnetLabs.nl> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This agenda is updated according to a suggestion by Jelte. The agenda is almost the same as the one by John. I have added a time schedule and question point number one. See below. Conference call arranged by Jelte: sip:conference at NLnetLabs.nl the pin number is 5227# If you don't have a sip phone or client available, the room should also be available at +31 20 7508314 extension 263 (just dial 263 when olaf's recorded voice starts talking) How about a Jabber channel? I can write minutes and email a summery. // Rickard - -------------------------- Agenda Time: 14:00 - 15:30 CET / 90 minutes 0a. Who writes minutes? 1. Project management (10 min) 1a. Who will be responsible? 1b. What responsibilities does this person have? 1c. Meetings? In real life? Jabber? Telephone? 2. Agree what the components are (System design) (35 min) 2a. Agree on the general system design 2b. Discuss any known contradictions on the wiki 2c. How do the components interface with each other in both the prototype and final systems 2d. Discuss technology to be used for each component 2e. Do we know the requirements for each component? 2f. Answer the question Matthijs asked in his email (see below) 3. Agree who is developing each component (6 min) 4. Discussion of the commitment needed for each component and available from each party. (6 min) 5. Brief update on the state of each component where possible (10 min) 6. Discuss and agree plan to move forward (10 min) 6a. Discuss timeline for whole project 6b. Decide on milestones for each component 6c. What about testing? 7. Decide on date of next meeting (3 min) 8. Agree actions (10 min) 8a. Who is writing any documentation still needed 8b. Who updates the wiki based on this meeting 8c. Other... List of questions from Matthijs 1. From the opendnssec.org website, I assume that the Signer has to determine the inception and expiration times on signatures. It can determine this from the refresh interval. (Ok, not a real question:)) 2. What's the difference between zone resigning interval and signature refresh interval? Imho, they are the same, but described differently. 3. What is the priority of changing security parameters? For example, it could be that the signature validity period has changed. Does this need to be applied to all signatures directly, or are they applied to upcoming generated signatures only? 4. What is meant with signature jitter and clockskew? Does this affect the zone content? If so, in what way? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSW3FCuCjgaNTdVjaAQjbPgf+MGwj58yKIiB8B6xqF8/mhA9+T3nBNjd8 34C/uhiuxTYz88OKy+WcJQE/ujOzheStvoEqw9RPGi/gVjIXP8CX+SkitERGgmi4 2AjOpzDvRaLVs4NlOYeen443D/3GaDTqA3ccTfrLHS19CeKSFTbn0Snoc9rnSTOO ylLZQ+9aDS9IFJSAQMhN1+Vi5bm2OIbTg3Zet2gfR0ztYrqhyQxn5UOo6o+bUUP1 aoo/4tlSRamsWyzJqt5zYHnoC98QUHvAZcGSHJj4vrMHkrHoqR5R+z04rW51GT6v MZ7FQDHan2qNxm/OvUs9pxlL+gWDN52aW06v0MO+BnDJbojJS33isg== =drr0 -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Wed Jan 14 10:57:49 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Wed, 14 Jan 2009 11:57:49 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: <20090114072516.GA13601@phantom.vanrein.org> Message-ID: <568169B7-6B18-4AB6-9BE5-088EA6371912@iis.se> On Jan 14, 2009, at 10:20 AM, Roy Arends wrote: > Rick van Rein wrote on 01/14/2009 08:25:16 AM: >> >> This is not as democratic as I had expected this to be. > > Rick, > > This project needs management, I lack time. Rickard Bondesson's > SoftHSM > part for OpenDNSSEC is mostly (if not completely) done. He > consistently > produced results for the SoftHSM part, while keeping an interest in > the > development of the OpenDNSSEC project, without getting into gory > details. > He is the obvious choice. This is not a democracy. There is no vote. I would also like to add my voice to support Rickard and having a project manager. He is after all working full time on the OpenDNSSEC project. We also need someone to oversee the project and to keep everything in sync. The goals has not really changed, and the issue of keeping zone states and so forth is not really an issue for the project, it is from my point of view only details. So we need somewhere down the line also look into all these issues in more detail. Now we obviosly found something to work more on, so we need a few people to sit down and plan how to do this. I believe Jelte's suggestion on having a face to face meeting soon is good. I would suggest the IETF, but I now that we all cannot get there, so maybe Amsterdam? I think Rickard will add this question to the agenda. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From rick at openfortress.nl Wed Jan 14 11:04:52 2009 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 14 Jan 2009 11:04:52 +0000 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <568169B7-6B18-4AB6-9BE5-088EA6371912@iis.se> References: <20090114072516.GA13601@phantom.vanrein.org> <568169B7-6B18-4AB6-9BE5-088EA6371912@iis.se> Message-ID: <20090114110452.GB21731@phantom.vanrein.org> Hi, > We also need someone to oversee the project and to keep everything in > sync. That is my only point. I have no opinions to vent about concrete people. As long as there is no interference with the technical mindset it will be possible to focus on milestones, progress, direction and so forth. Best, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Digital signature URL: From olaf at NLnetLabs.nl Wed Jan 14 11:32:25 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 12:32:25 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: <20090114072516.GA13601@phantom.vanrein.org> Message-ID: <68C502A9-B635-4AC6-B20C-D5ADFED6FA16@NLnetLabs.nl> On Jan 14, 2009, at 10:20 AM, Roy Arends wrote: > He consistently > produced results for the SoftHSM part, while keeping an interest in > the > development of the OpenDNSSEC project, without getting into gory > details. > He is the obvious choice. This is not a democracy. There is no vote. Hold it. Yesterday I decided not to start bitching about the unilateral decision as I assumed that I should not read that close and we would talk about the project management today. But those last two sentences make me dig up my draft mail of yesterday: In a collaboration it seems more than logical that a decision like this is being discussed by the several parties. It is not that I have anything against Rickard picking up the token, but it should not be a unilateral decision. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From roy at nominet.org.uk Wed Jan 14 11:45:18 2009 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 14 Jan 2009 12:45:18 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <68C502A9-B635-4AC6-B20C-D5ADFED6FA16@NLnetLabs.nl> References: <20090114072516.GA13601@phantom.vanrein.org> <68C502A9-B635-4AC6-B20C-D5ADFED6FA16@NLnetLabs.nl> Message-ID: Olaf Kolkman wrote on 01/14/2009 12:32:25 PM: > On Jan 14, 2009, at 10:20 AM, Roy Arends wrote: > > > He consistently > > produced results for the SoftHSM part, while keeping an interest in > > the > > development of the OpenDNSSEC project, without getting into gory > > details. > > He is the obvious choice. This is not a democracy. There is no vote. > > Hold it. > > Yesterday I decided not to start bitching about the unilateral > decision as I assumed that I should not read that close and we would > talk about the project management today. But those last two sentences > make me dig up my draft mail of yesterday: > > In a collaboration it seems more than logical that a decision like > this is being discussed by the several parties. It is not that I have > anything against Rickard picking up the token, but it should not be a > unilateral decision. You're reading to much into the last two sentences. It is not a democracy, hence there is no vote. This is also not an autocracy, so Rickard has added 'project management' to the agenda, where we can, if so desired, debate the process. I will motivate my actions. Roy From olaf at NLnetLabs.nl Wed Jan 14 11:52:26 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 12:52:26 +0100 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <20090114104208.GA21731@phantom.vanrein.org> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> <20090114091129.GB13601@phantom.vanrein.org> <2CECD06D-870C-4AA5-AC4F-18F592CE6FFC@NLnetLabs.nl> <20090114104208.GA21731@phantom.vanrein.org> Message-ID: <47A6853F-6314-4A2E-ADD6-84654AA4410B@nlnetlabs.nl> On Jan 14, 2009, at 11:42 AM, Rick van Rein wrote: > Olaf, > >> Skimming your documents I understand that you focus on the atomic >> coherency of possibly small sets of data (a couple of RRsets). The >> immediate question that I have is how you take care of zone >> coherency. > > The small (RRset size) changes that propagate through the dataflow end > at the zoneDB -- at that place, I imagine collecting all RRsets under > a zone until they are followed by a SOA. Then all up to then, > including > the SOA, is stored as an IXFR or AXFR into the zoneDB. I think I need to understand what the ZoneDB stores. In your picture I do not see any lines where when an IXFR is processed information is collected from the ZoneDB while deletion or additions of RRsets have impact on e.g. NSEC[3] RRs that exist in the database. Those will need to be maintained. > > This means that there is a transaction for each domain being signed, > maintained upon entry in the zoneDB. Or in other words, data is > being collected in a pre-publishing file and later moved into the > publication area if zoneDB is implemented in files. > I do not understand the above paragraph. A ZoneDB implementation means that you have to do the NSEC3 generation by seeking appropriate entries in the file. >> From a metalevel it is the operation on a zone that needs to be >> 'atomic'. I would need to be explained how you maintain that view >> within your design. > > 1a. Stuff comes in as an IXFR or AXFR, or > 1b. Stuff is created in response to internal needs I think I need to understand "internal needs". Internal to what? > > > 2. Stuff is passed on as RRset-sized "Diff" messages, each atomic, > with a SOA "Diff" closing a zone's changes > > 3. Stuff gets processed per RRset: NSEC(3) appended, SOA serial number > inserted, RRSet signing > There is not a one-to-one relation between NSEC3s and a processed RRset. Besides this suggest SOA number increase with each RRset (or I am misreading here, which is highly likely). > 4. Stuff gets collected and only published when the trailing SOA > drips in > > So the SOA record mirrors what "commit" does in a database. A new SOA > record is needed on any change, as its serial number must be updated. > And you'll never need more than one such change per zone update. So > it can serve as the "end of transaction" marker. > ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From Stephen.Morris at nominet.org.uk Wed Jan 14 12:11:44 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 14 Jan 2009 12:11:44 +0000 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 14/01/2009 10:49:12: > Agenda > > Time: 14:00 - 15:30 CET / 90 minutes > > 1. Project management (10 min) > 1a. Who will be responsible? > 1b. What responsibilities does this person have? > 1c. Meetings? In real life? Jabber? Telephone? > > 2. Agree what the components are (System design) (35 min) > 2a. Agree on the general system design > 2b. Discuss any known contradictions on the wiki > 2c. How do the components interface with each other in both the > prototype and final systems > 2d. Discuss technology to be used for each component > 2e. Do we know the requirements for each component? > 2f. Answer the question Matthijs asked in his email (see below) > > 3. Agree who is developing each component (6 min) > > 4. Discussion of the commitment needed for each component and > available from each party. (6 min) > > 5. Brief update on the state of each component where possible (10 min) > > 6. Discuss and agree plan to move forward (10 min) > 6a. Discuss timeline for whole project > 6b. Decide on milestones for each component > 6c. What about testing? > > 7. Decide on date of next meeting (3 min) > > 8. Agree actions (10 min) > 8a. Who writes minutes > 8b. Who is writing any documentation still needed > 8c. Who updates the wiki based on this meeting > 8d. Other... For the recent conversations on the list, it seems to me that although there is a general agreement as to what we are going to produce in principle, there is some confusion as to what are are going to produce in detail. I think it would be helpful if we could tackle this question before we get down to the system design (item 1.5?) In software development projects I've managed, I've found the following two documents useful: i) A project description: a general statement of the problem, a broad description of the solution, and identification of intended users. ii) A high-level use-case document: how is the completed software used by different users in different situations? I think that we should try to produce such high-level documents for this project, else I think we are in danger of (as we say in England) "not being able to see the wood for the trees". I've had a stab at producing a first draft of a project description - please feel free to comment: === A major obstacle to the widespread adoption of DNSSEC is the complexity of implementing it. There is no package that one can install on a system, click the "start" button, and have DNSSEC running. Instead, there are a variety of tools, none of which on their own is a complete solution. To actually run a DNSSEC-enabled authoritative server requires writing custom scripts to link them together. Even then, aspects of DNSSEC management such as key management and use of hardware assistance (such as HSMs) have not been adequately addressed. The aim of the OpenDNSSEC project is to produce software that will provide this comprehensive package. Installed on a system it will, with a minimum amount of operator input: * Handle the signing of DNS records, including the regular re-signing needed during normal operations. * Handle the generation and management of keys, including key rollover. * Seamlessly integrate with external cryptographic hardware such as HSMs. The OpenDNSSEC software will be applicable to a wide variety of DNS configurations, including (but not limited to): * Organisations (such as TLDs) that manage few zones, each with a large number of records. * Organisations (such as ISPs) that manage a large number of zones, each with few records. * Organisations (such as companies managing their own zones) that have a single zone with relatively few records. === Stephen From olaf at NLnetLabs.nl Wed Jan 14 12:51:48 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Wed, 14 Jan 2009 13:51:48 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: Thanks this first stab. But it does not answer an important question which I think is core to the debate we are having: How is this software supposed to integrate in existing environments? I think I've seen two different answers to that question: - As a component of the backend system generating zone files that can be read by a nameserver - As a component that acts as a "bump in the wire" - As a component that acts as a hidden master server - Others.... I think that you could take the first approach as a proof of concept to develop policies but I think another approach would need to be taken for a seriously scalable system. --Olaf On Jan 14, 2009, at 1:11 PM, Stephen.Morris at nominet.org.uk wrote: > A major obstacle to the widespread adoption of DNSSEC is the > complexity of > implementing it. There is no package that one can install on a > system, > click the "start" button, and have DNSSEC running. Instead, there > are a > variety of tools, none of which on their own is a complete > solution. To > actually run a DNSSEC-enabled authoritative server requires writing > custom > scripts to link them together. Even then, aspects of DNSSEC > management > such as key management and use of hardware assistance (such as HSMs) > have > not been adequately addressed. > > The aim of the OpenDNSSEC project is to produce software that will > provide > this comprehensive package. Installed on a system it will, with a > minimum > amount of operator input: > > * Handle the signing of DNS records, including the regular re-signing > needed during normal operations. > * Handle the generation and management of keys, including key > rollover. > * Seamlessly integrate with external cryptographic hardware such as > HSMs. > > The OpenDNSSEC software will be applicable to a wide variety of DNS > configurations, including (but not limited to): > > * Organisations (such as TLDs) that manage few zones, each with a > large > number of records. > * Organisations (such as ISPs) that manage a large number of zones, > each > with few records. > * Organisations (such as companies managing their own zones) that > have a > single zone with relatively few records. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jakob at kirei.se Wed Jan 14 12:52:30 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 14 Jan 2009 13:52:30 +0100 Subject: [Opendnssec-develop] 20080114 Meeting Agenda In-Reply-To: <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> Message-ID: On 14 jan 2009, at 11.57, Rickard Bondesson wrote: > How about a Jabber channel? please join xmpp:dnssec at conference.kirei.se jakob From matthijs at NLnetLabs.nl Wed Jan 14 15:07:21 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 14 Jan 2009 16:07:21 +0100 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> Message-ID: <496DFFA9.6070305@nlnetlabs.nl> Hi, We just decided to handle the questions on the list. So let me repeat my questions as well post some new ones: Question 1 is based on the assumption that the Signer Engine is responsible for re-signing. It is actually not a real question, but a remark: The Signer Engine determines the inception and expiration times on signatures given the refresh interval value it retrieved from KASP, right? Question 2: What's the difference between zone resigning interval and signature refresh interval? Imho, they are the same, but described differently. Question 3 from the list is already answered, since I have more insight in the flow of the OpenDNSSEC tool. Question 4: What is meant with signature jitter and clockskew? Does this affect the zone content? If so, in what way? And an extra question: Why should KASP store the TTL for NSECs. Shouldn't these be derived from the SOA's minimum field for negative caching? Cheers, Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From patrik.wallstrom at iis.se Wed Jan 14 15:54:01 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Wed, 14 Jan 2009 16:54:01 +0100 Subject: [Opendnssec-develop] Meeting minutes from todays meeting Message-ID: Please read and comment if I didn't get everything right. I will wait a few days until I publish this on the wiki. Meeting minutes 2009-01-14, OpenDNSSEC Jakob Schlyter Roy Arends John Dickinson Jelte Jansen Stephen Morris Rickard Bondesson Patrik Wallstr?m Matthijs Mekking Olaf Kolkman Rick van Rein Project management ------------------ Consensus decisions made by the group - not the project manager. The project manager acts as a "document shepherd", keeps the texts that are decided on... Rickard Bondesson has full support acting as the project manager from the group. Project manager responsibilites: - arrange meetings - keep documents - update the project plan First face to face meeting early February. Arrange the meetings with doodle. System design ------------- Agree on a high-level description of the system. Add this high-level description to the website. Long discussion on the inbound and outbound adapters, and on what OpenDNSSEC really is. First phase is? only complete signing with file input and output. Later on add IXFR with zone states and what we need with that. There is a need to describe the inbound and outbound adapters and how they interact with the unsigned and signed storage, and what is fed to the signer engine. Jakob and Roy will describe the data flow in OpenDNSSEC. Stephen will send a description of the KASP to the list, and also some example code. List decision on the API between the KASP Enforcer and the Signer Engine. We need the decision on the API between the Signer Engine and the zone storage modules. Next meeting, depends on data flow? We need use cases in order to make good decision on the design. Much of the API descriptions depend on missing details in the design. Post discussion material on the wiki separate from the decided design documents. Questions from Matthijs deferred to the mailing list. Who develops each component? ---------------------------- KASP Enforcer: John Dickinson Signer Engine, RRset Signer, NSEC-ifier: Jelte Jansen, NLNet Labs Unsigned/Signed-zone storage part of Signer Engine in phase 1. PKCS#11 should be tested by the party responsible for each component that must interact with the Security Module. Commitment ---------- Roy Arends - will participate on the list, and on the conference calls John Dickinson - 4 weeks? And spare time Jelte Jansen - 2-3 days per week Olaf Kolkman - Matthijs Mekking - 2-3 days per week Stephen Morris - ... Sean Rick van Rein - 1 day per week Roland - 1 day perl week Jakob Schlyter - 1 day per week? Patrik Wallstr?m - 1 day per week Brief update on the state of each component ------------------------------------------- Jelte: signed a zone using SoftHSM! Rickard: SoftHSM will be internally cleaner and extendable to other algorithms Stephen: Publish more details in KASP Prototype available in March? Not impossible, but April may be more realistic ... more details in the project plan. One reason to be finished in time is to present the project at HAR2009. Testing ------- Stephen: We must have unit testing and other testing - the code must be bullet proof. Will make test plan. Rick volounteers. Documents missing ------------------ Use cases: everybody mail or wiki Project plan: Rickard Data flow: Rick - needs feedback Stephen: High-level project description -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From Stephen.Morris at nominet.org.uk Wed Jan 14 15:57:35 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 14 Jan 2009 15:57:35 +0000 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: <496DFFA9.6070305@nlnetlabs.nl> Message-ID: Matthijs Mekking wrote on 14/01/2009 15:07:21: > Hi, > > We just decided to handle the questions on the list. So let me repeat my > questions as well post some new ones: > > Question 1 is based on the assumption that the Signer Engine is > responsible for re-signing. It is actually not a real question, but a > remark: The Signer Engine determines the inception and expiration times > on signatures given the refresh interval value it retrieved from KASP, > right? That's my understanding; KASP is just a database with logic that will allow it to list the keys that should be included in the zone (and which key should be used to sign it) at any given time. > Question 2: What's the difference between zone resigning interval and > signature > refresh interval? Imho, they are the same, but described differently. That sounds right, but I'm not sure - can anyone else comment? > Question 3 from the list is already answered, since I have more insight > in the flow of the OpenDNSSEC tool. > > Question 4: What is meant with signature jitter and clockskew? Does this > affect > the zone content? If so, in what way? As I understand it, signature jitter is a means by which the lifetime of signatures in a zone is varied around some mean so that you don't get all signatures expiring at the same time. Over a period of time, they should end up expiring at a continuous rate. This even out the load on a system where you are doing continuous signing. Clockskew is the (maximum) amount by which the clocks on the authoritative server and the validator differ. This needs to be taken into account else you could have a signature that is valid on the server but expired on the validator. > > And an extra question: Why should KASP store the TTL for NSECs. > Shouldn't these be derived from the SOA's minimum field for negative > caching? Not sure about this. Stephen From jakob at kirei.se Wed Jan 14 22:22:39 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 14 Jan 2009 23:22:39 +0100 Subject: [Opendnssec-develop] OpenDNSSEC Project Management In-Reply-To: References: Message-ID: <6F1E70E6-C01D-4069-BEE1-237E3A8E963B@kirei.se> I've put the text by Stephen on http://www.opendnssec.org/wiki/ Abstract for further processing. jakob From jakob at kirei.se Wed Jan 14 22:29:39 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 14 Jan 2009 23:29:39 +0100 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: <496DFFA9.6070305@nlnetlabs.nl> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> <496DFFA9.6070305@nlnetlabs.nl> Message-ID: On 14 jan 2009, at 16.07, Matthijs Mekking wrote: > Question 1 is based on the assumption that the Signer Engine is > responsible for re-signing. It is actually not a real question, but a > remark: The Signer Engine determines the inception and expiration > times > on signatures given the refresh interval value it retrieved from KASP, > right? correct, altough the signer engine receives configuration data form the kasp enforcer. the actual configuration data is calculated from the KASP (i.e. the policy), but you know that. > Question 2: What's the difference between zone resigning interval and > signature refresh interval? Imho, they are the same, but described > differently. no, they are not quite the same. for some applications (like we do for .se today) we want to run the a signer pass (the resigning interval). in that case the resigning interval is simply what we would have put in cron (.se will resign once every 2 hours, but will keep signatures that are within the refresh window). > Question 4: What is meant with signature jitter and clockskew? Does > this > affect the zone content? If so, in what way? jitter is used to tween the signature lifetimes in order to distribute signature expiration times. from the BIND docs (which I wrote): When signing a zone with a fixed signature lifetime, all RRSIG records issued at the time of signing expires simultaneously. If the zone is incrementally signed, i.e. a previously-signed zone is passed as input to the signer, all expired signatures have to be regenerated at about the same time. The jitter option specifies a jitter window that will be used to randomize the signature expire time, thus spreading incremental signature regeneration over time. Signature lifetime jitter also to some extent benefits validators and servers by spreading out cache expiration, i.e. if large numbers of RRSIGs don't expire at the same time from all caches there will be less congestion than if all validators need to refetch at mostly the same time. > And an extra question: Why should KASP store the TTL for NSECs. yes. > Shouldn't these be derived from the SOA's minimum field for negative > caching? could be, but you might want to tweek those more specific I guess. jakob From Rickard.Bondesson at iis.se Thu Jan 15 08:05:03 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 15 Jan 2009 09:05:03 +0100 Subject: [Opendnssec-develop] Face-to-Face February Message-ID: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 (Seems like we had some problem with our Exchange server yesterday. Trying to send again.) A face-to-face meeting between the participants of the OpenDNSSEC project. The decisions are about which date to meet on (in the beginning of February) and at which location (Oxford or Amsterdam). Follow the link to Doodle to make your opinion. http://www.doodle.com/grnbqp3cunxqhn62 An agenda will be published closer to the meeting. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSW7uL+CjgaNTdVjaAQgNOAf/WxKbiMtnx4GC2S8JEeTMxcKZcmdTrxow Hm8qnk9DeqMi9+Vt+yo0QffWlQiRawRssv0+funAbIX+kg/FXgXhJj1xZoctfA5J sCY9r15isPy9VrQQahRomr9RfkChh3hk9L5n2joJKeJs4GVwEkR7YgDMhXYaJrcx ozAe4Xl4eyK4OETW7YSJZa6E+IYB3LiyJDqovbUR9y2nH2HZDdcRLdusn65P3K6F kCSD03ooXsMr5eMP6trM2TTihqbWVL4Qco28PiKsCi9e6Wt7SdADC82tfQg8vtVA dxvWnAbvn7GoOyt98aiNLzdD20wMNz77u1DyiwXlrmQ0mvj/Jc3aTg== =vKjY -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Thu Jan 15 08:49:49 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 15 Jan 2009 09:49:49 +0100 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> <496DFFA9.6070305@nlnetlabs.nl> Message-ID: <76CD882C-FF6C-4EBB-9531-0E6F8D82A6A5@NLnetLabs.nl> FWIW: The fine distinction between singning and refresh seems a good definition to rfc4641-bis Sent from a phone; appologies for the telegram style this message might have. On 14 jan 2009, at 23:29, Jakob Schlyter wrote: > On 14 jan 2009, at 16.07, Matthijs Mekking wrote: > >> Question 1 is based on the assumption that the Signer Engine is >> responsible for re-signing. It is actually not a real question, but a >> remark: The Signer Engine determines the inception and expiration >> times >> on signatures given the refresh interval value it retrieved from >> KASP, >> right? > > correct, altough the signer engine receives configuration data form > the kasp enforcer. the actual configuration data is calculated from > the KASP (i.e. the policy), but you know that. > > >> Question 2: What's the difference between zone resigning interval and >> signature refresh interval? Imho, they are the same, but described >> differently. > > no, they are not quite the same. for some applications (like we do > for .se today) we want to run the a signer pass (the resigning > interval). in that case the resigning interval is simply what we > would have put in cron (.se will resign once every 2 hours, but will > keep signatures that are within the refresh window). > > >> Question 4: What is meant with signature jitter and clockskew? Does >> this >> affect the zone content? If so, in what way? > > jitter is used to tween the signature lifetimes in order to > distribute signature expiration times. from the BIND docs (which I > wrote): > > When signing a zone with a fixed signature lifetime, all > RRSIG > records issued at the time of signing expires > simultaneously. If > the zone is incrementally signed, i.e. a previously-signed > zone is > passed as input to the signer, all expired signatures have > to be > regenerated at about the same time. The jitter option > specifies a > jitter window that will be used to randomize the signature > expire > time, thus spreading incremental signature regeneration > over time. > > Signature lifetime jitter also to some extent benefits > validators > and servers by spreading out cache expiration, i.e. if large > numbers of RRSIGs don't expire at the same time from all > caches > there will be less congestion than if all validators need to > refetch at mostly the same time. > > >> And an extra question: Why should KASP store the TTL for NSECs. > > yes. > >> Shouldn't these be derived from the SOA's minimum field for negative >> caching? > > could be, but you might want to tweek those more specific I guess. > > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jad at jadickinson.co.uk Thu Jan 15 10:16:31 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 15 Jan 2009 10:16:31 +0000 Subject: [Opendnssec-develop] True Random Number Generator In-Reply-To: <69830D4127201D4EBD146B904119971864680E@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646649@EXCHANGE.office.nic.se> <20090107140412.GC1204@phantom.vanrein.org> <69830D4127201D4EBD146B904119971864666A@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B90411997186466C5@EXCHANGE.office.nic.se> <9A8FB9DA-0065-4103-B86F-6E1B3EB2CAFD@jadickinson.co.uk> <69830D4127201D4EBD146B90411997186466D2@EXCHANGE.office.nic.se> <37685BC2-8DDA-4A11-900A-4E8251DB4544@jadickinson.co.uk> <69830D4127201D4EBD146B904119971864680E@EXCHANGE.office.nic.se> Message-ID: <8DDB11F6-A9F2-4EA9-89EE-67D750025794@jadickinson.co.uk> On 13 Jan 2009, at 07:59, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> Well I really like softHSM - it is so easy to use and I >> really like the fact that it sort of creates users every time >> you use a different pin. - So simple :) > > :) > >> How about a debug mode where softHSM logs all the pkcs11 >> calls to a file (maybe something simple like if you link to a >> version of the lib called libsofthsm-DEBUG.so. (I am thinking >> of the debug mode of a AEP Keyper where it logs if you access >> it via a host name of HSML instead of HSM.) > > I will put it in my todo list. I just came across pkcs11-spy.so - part of opencryptoki. It seems to do what I was wanting. You link your app to pkcs11-spy.so and set an environment variable to point to the actual pkcs11 lib you want to use export PKCS11SPY=/usr/local/lib/libsofthsm.so then run the app and you get output like this *************** OpenSC PKCS#11 spy ***************** Loaded: "/usr/local/lib/libsofthsm.so" 0: C_GetFunctionList Returned: 0 CKR_OK 1: C_Initialize [in] pInitArgs = 0x7ffffdf9b000 Returned: 0 CKR_OK 2: C_GetInfo cryptokiVersion: 2.20 manufacturerID: ' SoftHSM ' flags: 0 libraryDescription: ' Implementation of PKCS11 ' libraryVersion: 0.1 Returned: 0 CKR_OK HTH John From Rickard.Bondesson at iis.se Thu Jan 15 10:33:59 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 15 Jan 2009 11:33:59 +0100 Subject: [Opendnssec-develop] Logging Message-ID: <69830D4127201D4EBD146B904119971864692E@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 What log information would like to be able to have in the system log? I am thinking about the SoftHSM: - - When the library is initialized/deinitialized? - - When a session is created/closed? - - When a user is logged in? - - When a key is created/deleted/modified? - - When (if possible) private key material is revealed? More? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSW8RF+CjgaNTdVjaAQgr0gf/emd1+b4UxA7mx3a5OyaoVO9B4O0vRSAG AfJHmN9jxNJnCSBUP68WX3/RHo1cYZyj5PRFEw/+JBEtmH2aT7OTMekkx0IdvmIg J/VUcusTJLyGnpYBytfVrJLnhBOorMrEhXoSRbVF/jNFtmKoFsdCTwyGttg1o6DT EK/YzDRnXlu/5yK1zVwj7J9LMeCpqo4i83a53dYJpZ0ZeGGCFBwyKbYeTpD1WofU rbeBzNGZqWEx/UCfqajpYn7YG9GouI/+X6c7R8ycw4Y7p913GAaxKRB08B+2fY44 o6/+UFhUsFlJavYDWN5OTBgTFEVExiEMWHBX7MmY0nUf57tuiQqHYg== =kxWS -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Thu Jan 15 10:41:32 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 15 Jan 2009 11:41:32 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> Message-ID: <3D904401-8636-4599-881E-5F996F6FB155@NLnetLabs.nl> On Jan 15, 2009, at 9:05 AM, Rickard Bondesson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > (Seems like we had some problem with our Exchange server yesterday. > Trying to send again.) > > A face-to-face meeting between the participants of the OpenDNSSEC > project. The decisions are about which date to meet on (in the > beginning of February) and at which location (Oxford or Amsterdam). I have no problem sending people to meetings, except that that provides budgetary pressure other than the ca 1.5 full time staff I've dedicated to the project. Tickets and expenses are real money that are eaten out of my travel budged. Any chance that those expenses can be reimbursed by other parties? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jad at jadickinson.co.uk Thu Jan 15 10:47:03 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Thu, 15 Jan 2009 10:47:03 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <3D904401-8636-4599-881E-5F996F6FB155@NLnetLabs.nl> References: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> <3D904401-8636-4599-881E-5F996F6FB155@NLnetLabs.nl> Message-ID: On 15 Jan 2009, at 10:41, Olaf Kolkman wrote: > > On Jan 15, 2009, at 9:05 AM, Rickard Bondesson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> (Seems like we had some problem with our Exchange server yesterday. >> Trying to send again.) >> >> A face-to-face meeting between the participants of the OpenDNSSEC >> project. The decisions are about which date to meet on (in the >> beginning of February) and at which location (Oxford or Amsterdam). > > > I have no problem sending people to meetings, except that that > provides budgetary pressure other than the ca 1.5 full time staff > I've dedicated to the project. Tickets and expenses are real money > that are eaten out of my travel budged. > > Any chance that those expenses can be reimbursed by other parties? Same here :) Travel money come out of my gadget fund :( John From Rickard.Bondesson at iis.se Thu Jan 15 15:13:49 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 15 Jan 2009 16:13:49 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880B198@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > A face-to-face meeting between the participants of the > OpenDNSSEC project. The decisions are about which date to > meet on (in the beginning of February) and at which location > (Oxford or Amsterdam). The Doodle tells us that the best time is 9th feb (Monday) in Oxford. The problem with Oxford is that we from Sweden only get 4 hours of meeting time because of the travel distance and available flights. And NLNetLabs got no travel budget. Second best option is 10th feb (Tuesday) in Amsterdam. I am willing to say that we should go for this date. Agree/disagree? Who is hosting? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSW9SreCjgaNTdVjaAQhD2gf+N5XUMCY8yGM94Sa09QxvGFGk0n1IpNRe ooPEaneAcP+PO2Ex6YqRXA7bVZrPJQg0rX9WUeubRYv+ehyhQkomoWPKzb1dK4o6 qFrhsAPrf8JJMEcrFMrgaSmvU8m5VJ/sDohhCJ8+Tg4xParwGvbog9Wlzvoe160f 9TKgzxvDwzhRNElUYqtWWfCvlnQ6Ba5Y8Suh6LJspsu79p4LoWWNBU/vlF5I5q1O aNjNHPqdYSXh8GVFIdR/ypviGKFdEQ/yJr35QU3lOcIlupkjD9a7RLLB/nLcTN00 4DaBiBjB/UOiP6QtdQ1b2vAqs82c6c3Lycrkma+XxoKpFB0hYerlTA== =Gb1p -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Thu Jan 15 16:18:28 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 15 Jan 2009 16:18:28 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B198@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 15/01/2009 15:13:49: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > A face-to-face meeting between the participants of the > > OpenDNSSEC project. The decisions are about which date to > > meet on (in the beginning of February) and at which location > > (Oxford or Amsterdam). > > The Doodle tells us that the best time is 9th feb (Monday) in > Oxford. The problem with Oxford is that we from Sweden only get 4 > hours of meeting time because of the travel distance and available > flights. And NLNetLabs got no travel budget. Can we please delay making a final decision for a day or so as I'm investigating whether I can get funding for NLNetLabs to travel? This may make a difference. Stephen (P.S. Regarding flying on the same day as you're doing business, my experience of a trip to Oslo for a morning meeting (some years ago, and in a previous job) went something like: * Decide to take 07:30 flight. * Need to check in at 06:30 latest. Better allow for a 30 minute delay (this is Heathrow after all), so make that 06:00 * Need to park the car at Heathrow and get to the terminal, allow 30 minutes for that - need to be at Heathrow by 05:30. * Hour's journey from home - leave by 04:30. * Hold on a minute, these are British motorways we are talking about - better make that 04:00. No knowing what part of the M4 they're digging up today. * Even I can get up and get ready in 30 minutes if I've packed the night before, so set alarm clock for 03:30 * Go to bed at 20:00 * Can't get to sleep until 22:30 * Worry about oversleeping, so wake every hour until time to get up at 03:30 * Despite my pessimism, I leave the house at 04:00, get down to Heathrow at 05:00, park the car by 05:10 and am through check-in by 05:30. * Into business lounge (the customer was paying!); drinks are free, but who wants a whisky at this time of the morning? * Drink free coffee for two hours, trying to stay awake and reflecting that the cost of coffee = (business fare - economy fare)/(number of cups). Boy, this is expensive coffee! * Get on plane and have breakfast - can't get to sleep because I've drunk too much coffee. * Arrive at Oslo an 09:30 and get to my meeting by 10:30. * Am too tired to concentrate properly, but manage to keep my eyes open all meeting (with lots more coffee). * Finally get to my hotel after a *long* day and am too tired to go out for a meal. No, I swore then that there would be no more early morning flights for me!) From jakob at kirei.se Thu Jan 15 18:55:04 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 15 Jan 2009 19:55:04 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B198@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B9041199718646914@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B198@EXCHANGE.office.nic.se> Message-ID: <631C6F0B-B366-49D3-BEC6-6A52622E15E8@kirei.se> would it be an option to have the meeting somewhere at Heathrow on the 9th? j From rick at openfortress.nl Thu Jan 15 19:36:50 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 15 Jan 2009 19:36:50 +0000 Subject: [Opendnssec-develop] interaction between the Signer and KASP In-Reply-To: <47A6853F-6314-4A2E-ADD6-84654AA4410B@nlnetlabs.nl> References: <494A4E88.6090109@nlnetlabs.nl> <494A6329.4060101@NLnetLabs.nl> <494A6B19.3080005@NLnetLabs.nl> <20090114091129.GB13601@phantom.vanrein.org> <2CECD06D-870C-4AA5-AC4F-18F592CE6FFC@NLnetLabs.nl> <20090114104208.GA21731@phantom.vanrein.org> <47A6853F-6314-4A2E-ADD6-84654AA4410B@nlnetlabs.nl> Message-ID: <20090115193650.GB28061@phantom.vanrein.org> Hello Olaf, About the data flow diagram I sent on the list yesterday: > I think I need to understand what the ZoneDB stores. The zoneDB stores an old AXFR plus a sequence of IXFR updates since the AXFR version. To avoid infinitely growing IXFR lists, the "IXFR to AXFR smasher" process will construct a new AXFR that integrates the old AXFR and one or more IXFR changes that were made to it. The "zone publish" process will serve IXFR when asked and when available, or AXFR otherwise. It may have to construct an AXFR out of the older AXFR and the sequence of IXFR following it. Or it could serve the AXFR and send a notify about any available IXFR. The Q4 queue basically drops RRsets as a next IXFR into the zoneDB, and commits the add as soon as a SOA has been added (the SOA being the end-marker of a change to the data). > In your picture I do not see any lines where when an IXFR is processed > information is collected from the ZoneDB while deletion or additions > of RRsets have impact on e.g. NSEC[3] RRs that exist in the database. > Those will need to be maintained. The idea is that the lines marked "Diff" also support DNS queries (I dubbed that "state-of-the-art DNS information in the text) that comes from the zoneDB, unless one of the queues through which the DNS queries travels has an answer. Each process that modifies data (like "RRset signer") may remove records (like RRSIG) from the RRset when responding to a "state-of-the-art DNS query" in the reverse direction of the "Diff" arrows. The result is that each queue responds with the same kind of data that is also put into it; for example, Q3 will contain (and respond with) NSEC3 data but Q2 has no NSEC3 records in it. So "state-of-the-art DNS info" requested trough Q2 will not surrender NSEC3, but going through Q3 will. If NSEC3 data is passed back from Q3 to Q2, the "add NSEC(3)" process will strip that part because it is confusing the Q2 and any process before it. It may well be that I have used clumsy terms, I couldn't find any better when I prepared this documentation. Suggestions for other terms are welcomed. > >This means that there is a transaction for each domain being signed, > >maintained upon entry in the zoneDB. Or in other words, data is > >being collected in a pre-publishing file and later moved into the > >publication area if zoneDB is implemented in files. > > I do not understand the above paragraph. The "Diff" arrows contain small bits of data to be signed, namely RRsets. The zoneDB holds larger units, namely the chunksize that gets a serial number and can be treated externally as a published version. The zoneDB collects the RRsets when they drip in over the "Diff" arrow from Q4, and calls it a complete version when the sequence of RRsets is ended with the SOA end-marker. As soon as the SOA comes in for the zone, the zoneDB knows that a new version is complete, and the IXFR for it moves to the publication area (or: the transaction representing the version's entry in the zoneDB is committed). > A ZoneDB implementation means that you have to do the NSEC3 generation > by seeking appropriate entries in the file. As soon as a new NSEC3PARAM arrives in the "add NSEC(3)" process, it will iterate all the names in the current file version. Thanks to the "state-of-the-art" DNS query mechanism, that includes any RRsets that may just have been changed for the zone. While iterating, all the hashes of all the names are created and ordered to know which holes are to be signed. I think it is good to iterate over the domain because it makes the complexity of ordering the zone (or: finding its holes) O(N*log(N)) -- using heapsort. If NSEC3 were to develop along with single insertions and removals, the creation of NSEC3 would end up costing O(N*N) as insertion-sort would be the mechanism used. N is the zone size, so that would be a problem for the larger zones. > >1a. Stuff comes in as an IXFR or AXFR, or > >1b. Stuff is created in response to internal needs > > I think I need to understand "internal needs". Internal to what? 1. DNSKEY rollover 2. NSEC3PARAM rollover (very rarely) 3. zone resigning > There is not a one-to-one relation between NSEC3s and a processed > RRset. Besides this suggest SOA number increase with each RRset (or I > am misreading here, which is highly likely). SOA serial numbers are increased when a SOA record arrives, and RRsets are collected until that happens. The sequence of RRsets, including the SOA, form a new IXFR for the zone. NSEC3 is not related to RR names, but to holes between them. So if a new RR name is introduced, two holes are created at its sides, and the old one into which the new name falls is removed. Similarly, if an RR name is removed, its neighbouring two holes are removed and a single new one is created to span the total range that used to be covered by the old two holes. It is immaterial AFAIK that a hash is applied to the name -- it merely means that the order is different from what it would be if an alphebatical ordering of names took place. But there still is a highly deterministic order that does not change if the NSEC3PARAM remains the same. Hope this helps -- and otherwise keep asking! Cheers, -Rick P.S. > NB: The street at which our offices are located has been > renamed to the above. I found that Google and bus drivers are not aware of this; it may be helpful to mention Kruislaan for a bit longer. From rick at openfortress.nl Thu Jan 15 19:49:17 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 15 Jan 2009 19:49:17 +0000 Subject: [Opendnssec-develop] Meeting minutes from todays meeting In-Reply-To: References: Message-ID: <20090115194917.GC28061@phantom.vanrein.org> Hi, > Project management > ------------------ > Consensus decisions made by the group - not the project manager. > The project manager acts as a "document shepherd", keeps the texts > that are decided on... > > Rickard Bondesson has full support acting as the project manager from > the group. > > Project manager responsibilites: > - arrange meetings > - keep documents > - update the project plan I'd like to add: - making sure to explicitly allocate time for project management - setting milestones and deliverables, and manage activities accordingly - write project plan > First face to face meeting early February. Arrange the meetings with > doodle. To add: The wiki is going to be filled with the agreed-upon content. A remark: someone (Jelte? Matthijs?) mentioned that another Wiki could be useful as a working notepad for developing documentation. > System design > ------------- > Agree on a high-level description of the system. Add this high-level > description to the website. > > Long discussion on the inbound and outbound adapters, and on what > OpenDNSSEC really is. First phase is? only complete signing with file > input and output. > Later on add IXFR with zone states and what we need with that. Actually, I thought I heard agreement on phase 1.1 Zone file in/out phase 1.2 AXFR in/out phase 2 IXFR in/out > There is a need to describe the inbound and outbound adapters and how > they interact with the unsigned and signed storage, and what is fed to > the signer engine. > > Jakob and Roy will describe the data flow in OpenDNSSEC. > > Stephen will send a description of the KASP to the list, and also some > example code. > > List decision on the API between the KASP Enforcer and the Signer > Engine. > > We need the decision on the API between the Signer Engine and the zone > storage modules. Next meeting, depends on data flow? > > We need use cases in order to make good decision on the design. Much > of the API descriptions depend on missing details in the design. > > Post discussion material on the wiki separate from the decided design > documents. > > Questions from Matthijs deferred to the mailing list. > > > Who develops each component? > ---------------------------- > > KASP Enforcer: John Dickinson > > Signer Engine, RRset Signer, NSEC-ifier: Jelte Jansen, NLNet Labs > > Unsigned/Signed-zone storage part of Signer Engine in phase 1. > > PKCS#11 should be tested by the party responsible for each component > that must interact with the Security Module. > > > Commitment > ---------- > Roy Arends - will participate on the list, and on the conference calls > > John Dickinson - 4 weeks? And spare time > > Jelte Jansen - 2-3 days per week > > Olaf Kolkman - > > Matthijs Mekking - 2-3 days per week > > Stephen Morris - ... Sean > > Rick van Rein - 1 day per week > > Roland - 1 day perl week His full name is Roland van Rijswijk > Jakob Schlyter - 1 day per week? > > Patrik Wallstr?m - 1 day per week > > > Brief update on the state of each component > ------------------------------------------- > Jelte: signed a zone using SoftHSM! > > Rickard: SoftHSM will be internally cleaner and extendable to other > algorithms > > Stephen: Publish more details in KASP > > Prototype available in March? Not impossible, but April may be more > realistic ... more details in the project plan. > > One reason to be finished in time is to present the project at HAR2009. > > > Testing > ------- > Stephen: We must have unit testing and other testing - the code must > be bullet proof. Will make test plan. Rick volounteers. To be precise, Rick volunteers to contact Stephen and help him testing the OpenDNSSEC system. > Documents missing > ------------------ > Use cases: everybody mail or wiki > Project plan: Rickard > Data flow: Rick - needs feedback > Stephen: High-level project description Thanks for making the notes. Cheers, -Rick From rick at openfortress.nl Thu Jan 15 20:27:52 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 15 Jan 2009 20:27:52 +0000 Subject: [Opendnssec-develop] Realtime scheduling... off the shelf? Message-ID: <20090115202752.GI28061@phantom.vanrein.org> Hello, The most worrysome concerns with DNSSEC would seem to be related to timing. I've spent some thought on how to get it all flowing well, and you inevitably end up with complicating reasonings like: 1. I can predict how long zone re-signing takes 2. I know when re-signing should be done 3. So I know when to start re-signing a zone 4. Let's keep some space for emergency re-signing popping up unexpectedly 5. Oops, what if all zones come in at once In other words, scheduling the signing processes is going to get complicated. Then I realised that our constraints may not in any way be special... there is a whole field of realtime scheduling expertise that we could exploit. Realtime schedulers usually manage tasks that occur at a regular interval, and mix several of those with timing as accurate as possible. They should also be able to add or withdraw any such interval-based actions, and to handle irregular extra jobs. The only "problem" with our domain would seem to be that our intervals span weeks, not milli-seconds. What do you guys think? Should we invent the wheel of real-time scheduling ourselves, or is there anything to be gained from using something already in existence? Is anyone experienced in or knowledgeable about this field? And, related, is it a fair question to ask the Signer Engine to initiate its own future operation? It could initially schedule a single re-signing but later versions may have better overall schedules if the Signer Engine actually set itself up as a repeating task. It's just a thought that might be useful to save us work. Best, -Rick From jakob at kirei.se Fri Jan 16 06:54:55 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 16 Jan 2009 07:54:55 +0100 Subject: [Opendnssec-develop] Realtime scheduling... off the shelf? In-Reply-To: <20090115202752.GI28061@phantom.vanrein.org> References: <20090115202752.GI28061@phantom.vanrein.org> Message-ID: On 15 jan 2009, at 21.27, Rick van Rein wrote: > What do you guys think? I think we should keep this possible problem in mind and postpone this until we actually see the problem. At this point we should concentrate the brain cycles of the project to actually get a working proof of concept. jakob From patrik.wallstrom at iis.se Fri Jan 16 08:38:31 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Fri, 16 Jan 2009 09:38:31 +0100 Subject: [Opendnssec-develop] Meeting minutes from todays meeting In-Reply-To: <20090115194917.GC28061@phantom.vanrein.org> References: <20090115194917.GC28061@phantom.vanrein.org> Message-ID: <25C4C732-9AB9-4351-A726-D0C9CDAE84F7@iis.se> On Jan 15, 2009, at 8:49 PM, Rick van Rein wrote: Thank you for your comments Rick. I added most of them to the minutes. [...] > A remark: someone (Jelte? Matthijs?) mentioned that another Wiki could > be useful as a working notepad for developing documentation. I am not sure that this is what we talked about, I believe we discussed to have separate wiki pages for draft items. Anobody else remember what we said? >> Long discussion on the inbound and outbound adapters, and on what >> OpenDNSSEC really is. First phase is? only complete signing with file >> input and output. >> Later on add IXFR with zone states and what we need with that. > > Actually, I thought I heard agreement on > > phase 1.1 Zone file in/out Wasn't this "phase 1"? > phase 1.2 AXFR in/out > phase 2 IXFR in/out Yes, something like that, I'll rewrite this portion of the text. >> Testing >> ------- >> Stephen: We must have unit testing and other testing - the code must >> be bullet proof. Will make test plan. Rick volounteers. > > To be precise, Rick volunteers to contact Stephen and help him testing > the OpenDNSSEC system. Ok. Next mail in this thread is the complete updates minutes. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From patrik.wallstrom at iis.se Fri Jan 16 08:39:11 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Fri, 16 Jan 2009 09:39:11 +0100 Subject: [Opendnssec-develop] revised - Meeting minutes from todays meeting In-Reply-To: <20090115194917.GC28061@phantom.vanrein.org> References: <20090115194917.GC28061@phantom.vanrein.org> Message-ID: <13C7A784-F680-4824-AE54-B774893A7615@iis.se> Meeting minutes 2009-01-14, OpenDNSSEC Jakob Schlyter Roy Arends John Dickinson Jelte Jansen Stephen Morris Rickard Bondesson Patrik Wallstr?m Matthijs Mekking Olaf Kolkman Rick van Rein Project management ------------------ Consensus decisions made by the group - not the project manager. The project manager acts as a "document shepherd", keeps the texts that are decided on... Rickard Bondesson has full support acting as the project manager from the group. Project manager responsibilites: - arrange meetings - keep documents - write project plan - update the project plan - setting milestones and deliverables, and manage activities accordingly - making sure to explicitly allocate time for project management First face to face meeting early February. Arrange the meetings with doodle. The wiki is going to be filled with the agreed-upon content. Some wiki pages might be discussion material. System design ------------- Agree on a high-level description of the system. Add this high-level description to the website. Long discussion on the inbound and outbound adapters, and on what OpenDNSSEC really is. We decided to do small steps for the inbound and outbound adapters, so there are three steps for developing these: - phase 1: Input and output zones on file - phase 1.1: Input and output zones using AXFR - phase 2: Input and output zones using IXFR Other input and output methods will be added later depending on use cases. There is a need to describe the inbound and outbound adapters and how they interact with the unsigned and signed storage, and what is fed to the signer engine. Jakob and Roy will describe the data flow in OpenDNSSEC. Stephen will send a description of the KASP to the list, and also some example code. List decision on the API between the KASP Enforcer and the Signer Engine. We need the decision on the API between the Signer Engine and the zone storage modules. Next meeting, depends on data flow? We need use cases in order to make good decision on the design. Much of the API descriptions depend on missing details in the design. Post discussion material on the wiki separate from the decided design documents. Questions from Matthijs deferred to the mailing list. Who develops each component? ---------------------------- KASP Enforcer: John Dickinson Signer Engine, RRset Signer, NSEC-ifier: Jelte Jansen, NLNet Labs Unsigned/Signed-zone storage part of Signer Engine in phase 1. PKCS#11 should be tested by the party responsible for each component that must interact with the Security Module. Commitment ---------- Roy Arends - will participate on the list, and on the conference calls John Dickinson - 4 weeks? And spare time Jelte Jansen - 2-3 days per week Olaf Kolkman - Matthijs Mekking - 2-3 days per week Stephen Morris - ... Sean Rick van Rein - 1 day per week Roland van Rijswijk - 1 day per week Jakob Schlyter - 1 day per week? Patrik Wallstr?m - 1 day per week Brief update on the state of each component ------------------------------------------- Jelte: signed a zone using SoftHSM! Rickard: SoftHSM will be internally cleaner and extendable to other algorithms Stephen: Publish more details in KASP Prototype available in March? Not impossible, but April may be more realistic ... more details in the project plan. One reason to be finished in time is to present the project at HAR2009. Testing ------- Stephen: We must have unit testing and other testing - the code must be bullet proof. Will make test plan. Rick volunteers to contact Stephen and help him testing the OpenDNSSEC system. Documents missing ------------------ Use cases: everybody mail or wiki Project plan: Rickard Data flow: Rick - needs feedback Stephen: High-level project description -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From patrik.wallstrom at iis.se Fri Jan 16 08:50:38 2009 From: patrik.wallstrom at iis.se (Patrik Wallstrom) Date: Fri, 16 Jan 2009 09:50:38 +0100 Subject: [Opendnssec-develop] Realtime scheduling... off the shelf? In-Reply-To: References: <20090115202752.GI28061@phantom.vanrein.org> Message-ID: <910277B8-728A-414B-A069-AC34353091A0@iis.se> On Jan 16, 2009, at 7:54 AM, Jakob Schlyter wrote: > On 15 jan 2009, at 21.27, Rick van Rein wrote: > >> What do you guys think? > > I think we should keep this possible problem in mind and postpone > this until we actually see the problem. At this point we should > concentrate the brain cycles of the project to actually get a > working proof of concept. I agree. But just to give you a simple a idea that I have been thinking about is just to set a priority on each batch job (if we call it that). Then we can have ordinary resigning that is not at all critical set to the lowest priority, and emergency signing at the highest. This is not at all related to real time processing, just batch processing in its simplest possible way. But in order to do this we must at least be thinking of having some sort of queue. The proof of concept should probably not include this at all, but might at least need a queue. So I think we need to discuss it anyway. -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From olaf at NLnetLabs.nl Fri Jan 16 08:59:25 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 16 Jan 2009 09:59:25 +0100 Subject: [Opendnssec-develop] Realtime scheduling... off the shelf? In-Reply-To: <20090115202752.GI28061@phantom.vanrein.org> References: <20090115202752.GI28061@phantom.vanrein.org> Message-ID: On Jan 15, 2009, at 9:27 PM, Rick van Rein wrote: > > The most worrysome concerns with DNSSEC would seem to be related to > timing. > I've spent some thought on how to get it all flowing well, and you > inevitably end up with complicating reasonings like: > > 1. I can predict how long zone re-signing takes > 2. I know when re-signing should be done > 3. So I know when to start re-signing a zone > 4. Let's keep some space for emergency re-signing popping up > unexpectedly > 5. Oops, what if all zones come in at once I don't see in what use cases this becomes relevant. Iff your signature validity intervals are so short that they interfere with resigning frequency and zone signing duration you seem to be on your way to the gun shop to inflict some serious foot pain. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From rick at openfortress.nl Thu Jan 15 19:59:19 2009 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 15 Jan 2009 19:59:19 +0000 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: References: <496DFFA9.6070305@nlnetlabs.nl> Message-ID: <20090115195919.GD28061@phantom.vanrein.org> Hello, > > Question 1 is based on the assumption that the Signer Engine is > > responsible for re-signing. It is actually not a real question, but a > > remark: The Signer Engine determines the inception and expiration times > > on signatures given the refresh interval value it retrieved from KASP, > > right? > > That's my understanding; KASP is just a database with logic that will > allow it to list the keys that should be included in the zone (and which > key should be used to sign it) at any given time. I think it makes sense to isolate cryptograpghic knowledge in KASP and DNS knowledge in the Signer Engine. It also happens to match the way the knowledge is distributed over groups, which means less interfaces to interact about. > > Question 2: What's the difference between zone resigning interval and > > signature > > refresh interval? Imho, they are the same, but described differently. > > That sounds right, but I'm not sure - can anyone else comment? I can imagine zones being resigned before signatures require refreshing, for reasons of zone transfer timing, signature validation timing, and such. Perhaps cache storing times also play a part. Not sure where you found these terms, but this is how I read them. > > Question 4: What is meant with signature jitter and clockskew? Does this > > affect > > the zone content? If so, in what way? > > As I understand it, signature jitter is a means by which the lifetime of > signatures in a zone is varied around some mean so that you don't get all > signatures expiring at the same time. Over a period of time, they should > end up expiring at a continuous rate. This even out the load on a system > where you are doing continuous signing. Ah, that's different from what I assumed with these terms. I only know jitter as undesirable timing variations, not desired ones. Aside from the fact that what you are describing is good, this is what I read in the terms: Distributed systems each do their own timekeeping -- and not always very accurately. As a matter of fact, Einstein taught us that there is no concept of distributed same-time occurrences. NTP is fighting hard to pin down Einstein's reasonings to the smallest possible differences in timing accross servers, but not to zero. Milliseconds are common, at least that's what I've seen. When you use a primary clock source such as a GPS device you still get into trouble if it takes you long to read the data and/or process it. That's the sort of thing that I have in mind when we speak of timing jitter and clock skew. > Clockskew is the (maximum) amount by which the clocks on the authoritative > server and the validator differ. This needs to be taken into account else > you could have a signature that is valid on the server but expired on the > validator. Yes. > > And an extra question: Why should KASP store the TTL for NSECs. > > Shouldn't these be derived from the SOA's minimum field for negative > > caching? > > Not sure about this. I agree with anyone who wants to keep KASP as much as possible dedicated to cryptography, and pull away complicating (error and hole causing) aspects of DNS. My ideal would be to have KASP equal to PKCS #11... If anyone has a good idea about the influence of SOA timing parameters on the DNSSEC framework, I think it should make a good read on this list, because I at least am a bit weary about what its influences are. -Rick From Rickard.Bondesson at iis.se Fri Jan 16 09:20:54 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 16 Jan 2009 10:20:54 +0100 Subject: [Opendnssec-develop] Project plan Message-ID: <69830D4127201D4EBD146B904119971880B1D0@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Here is my first draft on the project plan. Still missing some peaces like a more detailed time plan, since we need to plan the components a little bit more first. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXBRduCjgaNTdVjaAQj5GAgAhNJcMtrDGa1dpuK5/BeSfV7HeGg7avRj 6U6ne5cz4itRhpnryhSUferV+GFF558m2AGadbb2fc8+X4PwxehiOFAZEmMVYQr9 qykNGDXycYNNhsSaizYYVWvRbDgZVDun2/Y4chZU2TE/yN2LiLddsMxTkVtBb9ak KnCH2d5QE3Bya7unr7YGSjoktNTnCBIN7ln0vBd7GB3p2kxCZdicl6+Izr6ZDMl1 RR2xlu7ABzuGDCZhmQu7Xljc4U8B+eefRjN1YlVWpFXbOqrRzzCAYQnKFHhr8s1O 6ZK1joi4ELfaoEvO7PZajAL0m0pYXBA4sLXfcG+Z9KJAJeutlc6hpw== =z6lm -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenDNSSEC.Project.Plan.v0.1.pdf Type: application/octet-stream Size: 102771 bytes Desc: OpenDNSSEC.Project.Plan.v0.1.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenDNSSEC.Project.Plan.v0.1.pdf.sig Type: application/octet-stream Size: 486 bytes Desc: not available URL: From olaf at NLnetLabs.nl Fri Jan 16 10:28:06 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 16 Jan 2009 11:28:06 +0100 Subject: [Opendnssec-develop] revised - Meeting minutes from todays meeting In-Reply-To: <13C7A784-F680-4824-AE54-B774893A7615@iis.se> References: <20090115194917.GC28061@phantom.vanrein.org> <13C7A784-F680-4824-AE54-B774893A7615@iis.se> Message-ID: <767DBDAB-A68F-485A-9D6B-268D4B025723@NLnetLabs.nl> Filling in a blank spot. > > Commitment > ---------- > Roy Arends - will participate on the list, and on the conference calls > > John Dickinson - 4 weeks? And spare time > > Jelte Jansen - 2-3 days per week > > Olaf Kolkman - Ca an hour or two per week. I see my role mostly as making sure there are no dead-locks for NLnet Labs commitment to proceed. And also try to take a way lessons learned for RFC 4641 bis. Further, as said on the call, I am interested in "Version 2" and while our first priority is on getting Versions 1 working I want to continue with Version 2 and architecting that in parallel. Wouter will be in the loop too, but also for version 2 and from a 'spare time' perspective. > Matthijs Mekking - 2-3 days per week > > Stephen Morris - ... Sean > > Rick van Rein - 1 day per week > > Roland van Rijswijk - 1 day per week > > Jakob Schlyter - 1 day per week? > > Patrik Wallstr?m - 1 day per week ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From roland.vanrijswijk at surfnet.nl Fri Jan 16 13:52:30 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Fri, 16 Jan 2009 14:52:30 +0100 Subject: [Opendnssec-develop] Project plan In-Reply-To: <69830D4127201D4EBD146B904119971880B1D0@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B1D0@EXCHANGE.office.nic.se> Message-ID: <4970911E.9000707@surfnet.nl> Hi Rickard, First of all: my compliments on a good start for a project plan, I know it's far from complete but it seems like a good start. I saw that one of the deliverables mentioned is a project website. I think you should specifically assign this task to someone; I just got off the phone with the RIPE NCC and they said "yeah, we looked at OpenDNSSEC because Olaf mentioned it to us but have you looked at their website? It doesn't actually say very much". I told them a little bit about the stage OpenDNSSEC is in and they were very enthusiastic about it. So in order for OpenDNSSEC to get some outside attention I think it would be really helpful to up the ante on the website a bit, and it would also help if some info about the project were to be posted on common lists (DNS-ops, RIPE DNS WG, etc.) Unfortunately, as you also mentioned, I don't have much time myself to spend on this so I'm not able to volunteer for this :-( Cheers, Roland Rickard Bondesson wrote: > Hi > > Here is my first draft on the project plan. Still missing some peaces like a more detailed time plan, since we need to plan the components a little bit more first. > > // Rickard ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Stephen.Morris at nominet.org.uk Fri Jan 16 14:11:24 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 16 Jan 2009 14:11:24 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: Message-ID: Stephen.Morris at nominet.org.uk wrote on 15/01/2009 16:18:28: > "Rickard Bondesson" wrote on 15/01/2009 > 15:13:49: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > > A face-to-face meeting between the participants of the > > > OpenDNSSEC project. The decisions are about which date to > > > meet on (in the beginning of February) and at which location > > > (Oxford or Amsterdam). > > > > The Doodle tells us that the best time is 9th feb (Monday) in > > Oxford. The problem with Oxford is that we from Sweden only get 4 > > hours of meeting time because of the travel distance and available > > flights. And NLNetLabs got no travel budget. > > Can we please delay making a final decision for a day or so as I'm > investigating whether I can get funding for NLNetLabs to travel? This may > make a difference. > > Stephen If the meeting is held in Oxford, Nominet can meet NLNetLabs's travel and accommodation costs. Stephen From olaf at NLnetLabs.nl Fri Jan 16 14:27:46 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 16 Jan 2009 15:27:46 +0100 Subject: [Opendnssec-develop] Questions unanswered In-Reply-To: <76CD882C-FF6C-4EBB-9531-0E6F8D82A6A5@NLnetLabs.nl> References: <69830D4127201D4EBD146B9041199718646891@EXCHANGE.office.nic.se> <496DC418.5090403@NLnetLabs.nl> <69830D4127201D4EBD146B9041199718646896@EXCHANGE.office.nic.se> <496DFFA9.6070305@nlnetlabs.nl> <76CD882C-FF6C-4EBB-9531-0E6F8D82A6A5@NLnetLabs.nl> Message-ID: On Jan 15, 2009, at 9:49 AM, Olaf Kolkman wrote: > FWIW: The fine distinction between singning and refresh seems a good > definition to rfc4641-bis Before exposing this RFC4641bis issue to DNSOP please have a look at: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology The definitions are kind of sketchy. Better wording is welcome. Note that in 4641 we used Period, but Interval and Frequency seem to be good terms too. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From Rickard.Bondesson at iis.se Fri Jan 16 14:45:10 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 16 Jan 2009 15:45:10 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > If the meeting is held in Oxford, Nominet can meet > NLNetLabs's travel and accommodation costs. Ok. The best day according to Doodle is Mon 9th Feb in Oxford. The only one who can not this day is Jelte, but he said that he could shuffle some things in his schedule and still make it as long as he can travel back and forth on the same day. So let?s say: Meeting in Oxford Mon 9th Feb. Host: Nominet We from Sweden can be in Oxford between 11-18 to be able to match our flights. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXCdduCjgaNTdVjaAQjaMAf/Tx/du9exNng0h1E9hF3i/LAw0yPL2pLz 6ptuyr4R9Zhcn1ohIY0KWlgUITUiiC/xX4jJ7xWm6JpfziBc2L03CAZpaPZ8a4pq p5VbKCymGa198nuayBh42oEXTf7U8MAdBkPjlot9v5B7ONsUOOrD5ZT1IzZ9S/Yf ql1tyYbesrFLz/PRKeWIgWAhtLKoskYuCefQlspys9Fb9RZjKPA5Jiq1ElpQe3OB aJyWekHxiAb7+jENvC5t5YCr02EDeegQdnY4gP0XnaZBelErzethYBXQ/0gkiYZg OdX/FoXpPT7r1rot9KycQvE30MD8iNB/YdpzC1+FTABOIp6KYe3dfA== =jSqb -----END PGP SIGNATURE----- From rick at openfortress.nl Fri Jan 16 15:17:41 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 16 Jan 2009 15:17:41 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> Message-ID: <20090116151741.GA7795@phantom.vanrein.org> H'm, > Ok. The best day according to Doodle is Mon 9th Feb in Oxford. The only one who can not this day is Jelte, but he said that he could shuffle some things in his schedule and still make it as long as he can travel back and forth on the same day. It would seem that Oxford does not have an airport. That may mean using the public transport for the majority of people. I start to wonder if Amsterdam isn't *much* more practical... Oxford people, can you give us hints on how to travel best? I've tried getting through to the public transport system of the UK in the past, and it turned out to be all but straightforward. -Rick From jakob at kirei.se Fri Jan 16 15:29:16 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 16 Jan 2009 16:29:16 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <20090116151741.GA7795@phantom.vanrein.org> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org> Message-ID: <5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se> On 16 jan 2009, at 16.17, Rick van Rein wrote: > It would seem that Oxford does not have an airport. That may mean > using > the public transport for the majority of people. I start to wonder if > Amsterdam isn't *much* more practical... I believe AMS is better, but that is also becuse it would not involve LHR. jakob From Rickard.Bondesson at iis.se Fri Jan 16 15:37:23 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 16 Jan 2009 16:37:23 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org> <5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OK We are doing a new Doodle with a choice between Oxford and Amsterdam, 9 & 10 feb. And consider the argumentation you have heard on the mailing list. http://www.doodle.com/k6durcvme583d4h6 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXCps+CjgaNTdVjaAQgO/wf8DB2gnQWGJBz6N6wDCGZPdoZK2BkaaXLf 2btLPnmtC7kXEO5QVgmlSlmXqL/k61HGshV7OiyLtHTsNvP7Ll12gGjxE1xQe2dA 2k9x6bNplVzn/ieIn8Pqn+hXfxGieujyhcAfOkf3YpDiLAdpdoC4DACeFij/6YtO 5j8C+fia7ObvuctTVLReMAj1Rhs57F5uaNN2VKVdjcfOcJDPQksQWqbyc6UqKoQP ghuljtPHqga7g+8YeMFeRdYLCDKdfPl7wDxEuNeZeznD6clt4XPWyfW/KF2SzEco BBjECVrekFOtxQgDGzXY3xlradx5J8Gvo608tFrCbOGvk3gGHxBEVw== =3C7g -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Fri Jan 16 15:43:40 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 16 Jan 2009 15:43:40 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <20090116151741.GA7795@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 16/01/2009 15:17:41: > H'm, > > > Ok. The best day according to Doodle is Mon 9th Feb in Oxford. The > only one who can not this day is Jelte, but he said that he could > shuffle some things in his schedule and still make it as long as he > can travel back and forth on the same day. > > It would seem that Oxford does not have an airport. That may mean using > the public transport for the majority of people. I start to wonder if > Amsterdam isn't *much* more practical... > > Oxford people, can you give us hints on how to travel best? I've tried > getting through to the public transport system of the UK in the past, > and it turned out to be all but straightforward. > > -Rick If there are enough people arriving together, we might be able to organise a car. However, there is a regular and frequent coach between Heathrow and the main bus station in central Oxford, which is only a short walk from the hotel where Roy usually stays when he comes over. It's about a 90-minute journey and claims to have free WiFi on board. See http://www.oxfordbus.co.uk/main.php?page_id=24 I'll have a word with Michelle (the PA to our IT director, and the person who does all our travel arrangements) on Monday and see what she recommends. Stephen From roy at nominet.org.uk Fri Jan 16 15:46:08 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Jan 2009 16:46:08 +0100 Subject: [Opendnssec-develop] What about 27, 28 or 29th of January in Oxford. In-Reply-To: <69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org> <5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se> <69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> Message-ID: Since we're re-doodling anyway, I thought I throw in another option. Roy From jakob at kirei.se Fri Jan 16 15:46:21 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 16 Jan 2009 16:46:21 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: References: Message-ID: On 16 jan 2009, at 16.43, Stephen.Morris at nominet.org.uk wrote: > If there are enough people arriving together, we might be able to > organise > a car. However, there is a regular and frequent coach between > Heathrow > and the main bus station in central Oxford, which is only a short walk > from the hotel where Roy usually stays when he comes over. It's > about a > 90-minute journey and claims to have free WiFi on board. See > http://www.oxfordbus.co.uk/main.php?page_id=24 2x90 minutes bus for a one day meeting + the extra time for all the fuzz at LHR. ouch... jakob From Rickard.Bondesson at iis.se Fri Jan 16 16:00:09 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Fri, 16 Jan 2009 17:00:09 +0100 Subject: [Opendnssec-develop] What about 27, 28 or 29th of January in Oxford. In-Reply-To: References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org><5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se><69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880B21B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Since we're re-doodling anyway, I thought I throw in another option. Sure. A meeting sooner can be good, but we decided that we should have it in the beginning of febrary. We can not discuss for a long time. Any special reason why these dates? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXCvCeCjgaNTdVjaAQj3RggAqX6v1pt+OTF0HjtOPqbpH91pRgH6aADf HkGLDrppsBV4cTpQeILFpIcjBWGSbMnMxIC6TjAAtob9aFbZCJ6FZPN1cYxywGbZ 8tbJSE4ShVj6zpBIBrUk4+itVarQWJL9dZEz/xsXWOoNFI4Qr4YxJctY6czeHzHs Iv3mhpm/r2VJbPcl1O1q/SkqH4kdVi4CQy/SaBQHQZSc85KamJR9JpoYayP+Fbwh n60d/Kl4LrgTfq8qZwMeuxz1BRR+WjsXoyVz2SJfNaw/GIBFXbiOkz2IlLQ1oFlB HCyzYsR9k0T1wJqn18PwSbuPT+4SpIx9FO0rsIOJ4u0B7nIqgoRi+w== =CdsW -----END PGP SIGNATURE----- From roy at nominet.org.uk Fri Jan 16 16:04:29 2009 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Jan 2009 17:04:29 +0100 Subject: [Opendnssec-develop] What about 27, 28 or 29th of January in Oxford. In-Reply-To: <69830D4127201D4EBD146B904119971880B21B@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org><5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se><69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B21B@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 01/16/2009 05:00:09 PM: > > Since we're re-doodling anyway, I thought I throw in another option. > > Sure. A meeting sooner can be good, but we decided that we should > have it in the beginning of febrary. We can not discuss for a long > time. Any special reason why these dates? I've to be in oxford the last week of january anyway, and also 10 & 11 february (though not available during these two dates for openDNSSEC). The first week of Februari I'm in Atlanta. I'm trying to wiggle it all in this very tight schedule. Hence the new options. Before throwing this option out, what do others feel about the last week of January ? Roy From jakob at kirei.se Fri Jan 16 16:12:31 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 16 Jan 2009 17:12:31 +0100 Subject: [Opendnssec-develop] What about 27, 28 or 29th of January in Oxford. In-Reply-To: References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org><5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se><69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B21B@EXCHANGE.office.nic.se> Message-ID: On 16 jan 2009, at 17.04, Roy Arends wrote: > Before throwing this option out, what do others feel about the last > week > of January ? I can do january 29th if really needed. GOT-LHR arr 08:25, LHR-GOT dep 18:40. would it be an option to meet at LHR? that would save a lot of time for most people. jakob From Stephen.Morris at nominet.org.uk Fri Jan 16 16:36:48 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 16 Jan 2009 16:36:48 +0000 Subject: [Opendnssec-develop] Face to face - choice of location/date In-Reply-To: Message-ID: Jakob Schlyter wrote on 16/01/2009 16:12:31: > On 16 jan 2009, at 17.04, Roy Arends wrote: > > > Before throwing this option out, what do others feel about the last > > week > > of January ? > > I can do january 29th if really needed. GOT-LHR arr 08:25, LHR-GOT dep > 18:40. > > would it be an option to meet at LHR? that would save a lot of time > for most people. > > > jakob If people don't want to stay overnight, then I think that Oxford is probably out - even by car, the journey between Heathrow and Nominet will add at least an hour each way onto the travel time. The bus journey time of 90 minutes each way is to the centre of oxford - add 20 minutes or so to get to Nominet from there. So it does seem as if we are looking at Amsterdam or a hotel near Heathrow. Stephen From jad at jadickinson.co.uk Fri Jan 16 16:39:11 2009 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 16 Jan 2009 16:39:11 +0000 Subject: [Opendnssec-develop] What about 27, 28 or 29th of January in Oxford. In-Reply-To: References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <20090116151741.GA7795@phantom.vanrein.org><5161D687-8294-406C-99F3-A51A58B0BB91@kirei.se><69830D4127201D4EBD146B904119971880B215@EXCHANGE.office.nic.se> <69830D4127201D4EBD146B904119971880B21B@EXCHANGE.office.nic.se> Message-ID: Hi, I am away from tomorrow up to and including the 25th Jan and I don't know if I will have access to email. Here is my schedule for the following weeks I am free all the time from the 26th Jan - 28th Feb except on the following dates 27th Jan 29th Jan I could possibly make the 29th Jan if Stephen can re-arrange my meetings with him and Ian at Nominet. I would prefer to meet in Oxford because I can stay in bed longer. LHR is second best and Amsterdam is my third choice. See you all soon. John P.S. Please let me know when it is safe to book any required flights :) On 16 Jan 2009, at 16:12, Jakob Schlyter wrote: > On 16 jan 2009, at 17.04, Roy Arends wrote: > >> Before throwing this option out, what do others feel about the last >> week >> of January ? > > I can do january 29th if really needed. GOT-LHR arr 08:25, LHR-GOT > dep 18:40. > > would it be an option to meet at LHR? that would save a lot of time > for most people. > > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- John Dickinson http://www.jadickinson.co.uk From rick at openfortress.nl Sat Jan 17 22:18:00 2009 From: rick at openfortress.nl (Rick van Rein) Date: Sat, 17 Jan 2009 22:18:00 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC Message-ID: <20090117221800.GA5422@phantom.vanrein.org> Hello, I've taken the liberty of drawing up a Use Case diagram, describing OpenDNSSEC as it interacts with its environment. This can be found on a working page with OpenDNSSEC design documents: http://openfortress.nl/tmp/opendnssec/ Comments and updates are welcome. The whole idea of making these design documented is to check if we have the same mindset. If you see anything "funny" you should therefore speak up :) I also drew up Message Sequence diagrams for the Signer, and will digitise those soon. Best wishes, -Rick From jelte at NLnetLabs.nl Sun Jan 18 13:23:30 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Sun, 18 Jan 2009 14:23:30 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> Message-ID: <49732D52.8090206@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: >> If the meeting is held in Oxford, Nominet can meet >> NLNetLabs's travel and accommodation costs. > > Ok. The best day according to Doodle is Mon 9th Feb in Oxford. The only one who can not this day is Jelte, but he said that he could shuffle some things in his schedule and still make it as long as he can travel back and forth on the same day. > err, i think i was a bit unclear about it; I can stay overnight. In fact, it would probably be easier for me since I don't exactly live close to the airport here. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklzLUoACgkQ4nZCKsdOncUXlQCfQX0z4m1kCoh43yB/JansuFmf ZjUAoMbW5ptFN6GaGvkHXHtMjpX8DsJS =GQck -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Mon Jan 19 08:55:49 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 19 Jan 2009 09:55:49 +0100 Subject: [Opendnssec-develop] Face to face - choice of location/date In-Reply-To: References: Message-ID: <69830D4127201D4EBD146B904119971880B23B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > So it does seem as if we are looking at Amsterdam or a hotel > near Heathrow. Is it possible to arrange a meeting venue near Heathrow? So we can decide where to have the meeting. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXRAFeCjgaNTdVjaAQhnFgf+P6IbfJRakLU5lT367JGunPsb//o8HKOy 27wRUwCxISTIgssUcsLXbIQ6A6eyqfdmQuwj69xUjLCWiu6xcQ6jWkrqR6EDVJ4x ns6qla00T28FMGG2dO4wgT025fywLzBMbWaBZJvd6YhneY2pg66xdYUSP+ND9GjK dglR2Xl0yXRKNk7Z+zlkQ5uB43YHN299jRAxrsO6yooa8O1H7pxdnOlXyJEgXB1y OW8/Lag+T1JaYvXUIt+7nb7kIWW19GmdKPw0t3J1/OBs0CqFXPKtMgqRTYbhxlv5 /vIWccJk3mKLS6enGeEosiJH3AOxv/Rhk/ddsl5kQxXg018kmLfrWQ== =I/I4 -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Mon Jan 19 09:54:58 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 19 Jan 2009 10:54:58 +0100 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <20090117221800.GA5422@phantom.vanrein.org> References: <20090117221800.GA5422@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971880B24F@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I've taken the liberty of drawing up a Use Case diagram, > describing OpenDNSSEC as it interacts with its environment. > This can be found on a working page with OpenDNSSEC design documents: Great initiative! Comes in handy when you would like a summarization of the different use cases and that our software conforms to the intended use. Also a good start when we are doing a security review with tools like misuse cases. > http://openfortress.nl/tmp/opendnssec/ > > Comments and updates are welcome. The whole idea of making > these design documented is to check if we have the same > mindset. If you see anything "funny" you should therefore speak up :) Is it possible to add a security level to each component of the data flow diagram (DFD)? White/black/grey meaning that the incoming data/resource is trusted/untrusted/somewhat-trusted. Useful when evaluating the source code for any security holes. The DFD is essentially a more detailed description on the Signer Engine with its surrounding. Any comments by the Signer Engine development team? Does this conform to your mindset? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXRN8uCjgaNTdVjaAQikhgf+LBXjucE++D5+sqJ/Jcu87Cm8Gsb37Csg VCxrDK22t/ClBaUiEusBUwQDKWY9CuqngvuwF9d5DjacZYktJdqUTiL3FcHCJHDW ejZCo4fmee9djAtz6wOX2L/XnL5XG0jxZDfB0g+HfhvChCnMozSFI7FS+kyKCZRE YFfUYg5SC3P28USt+lZKZAtaWolTJwtk/aeiKV/tdyzBGZFNzFUlRqyeFDx6NmHx gU1SO5oikMEjcGZyuAjF+K5IiLSZwgUE/W/FxJIFUBvkVJtyvGZZwd8i4/mCSZ/O ebTB87tOiQsDqyX53A3sh4+kceP06zzhk24tdnVTP/fq1gaP8+ejeQ== =V+qD -----END PGP SIGNATURE----- From roy at nominet.org.uk Mon Jan 19 10:19:35 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 19 Jan 2009 11:19:35 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <49732D52.8090206@NLnetLabs.nl> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> Message-ID: Jelte wrote on 01/18/2009 02:23:30 PM: > Rickard Bondesson wrote: > >> If the meeting is held in Oxford, Nominet can meet > >> NLNetLabs's travel and accommodation costs. > > > > Ok. The best day according to Doodle is Mon 9th Feb in Oxford. The > only one who can not this day is Jelte, but he said that he could > shuffle some things in his schedule and still make it as long as he > can travel back and forth on the same day. > > > > err, i think i was a bit unclear about it; I can stay overnight. In fact, it > would probably be easier for me since I don't exactly live close to > the airport > here. Jelte, does this mean that you are available for monday the 9th, if you'd allow for an overnight stay in Oxford (on either the 8th or the 9th)? If that is the case, it seems that, according to doodle, we're all available for the 9th in Oxford. Regards, Roy Arends Sr. Researcher Nominet UK From jelte at NLnetLabs.nl Mon Jan 19 10:21:20 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 19 Jan 2009 11:21:20 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> Message-ID: <49745420.5020203@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roy Arends wrote: > > Jelte, does this mean that you are available for monday the 9th, if you'd > allow for an overnight stay in Oxford (on either the 8th or the 9th)? > > If that is the case, it seems that, according to doodle, we're all > available for the 9th in Oxford. > yes Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl0VB8ACgkQ4nZCKsdOncUh/QCeKVyms9e6SReNBO7e3tjG5epC /B0AoJ28TgPB3t1deOx51QoMTQojeMdf =KMy1 -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Mon Jan 19 10:58:59 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 19 Jan 2009 11:58:59 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <49732D52.8090206@NLnetLabs.nl> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OK, it seems like we have reached a decision after multiple email conversations and Jabber chatting. Meeting in Amsterdam Mon 9th Feb. Host: NLNetLabs // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXRc8+CjgaNTdVjaAQgOBgf9Fm415KDWhRCQ9c3/RrezVGXltDO/h9sM ZeXRuZQ3TBD09KqwrJ2Ct4EkjlYacoBUXoNrXTRGnThCPOCIcOhl3bY+zWytPfE6 Y8SInVmlo6eRYFSnoeQG2u/b1yFtENW67OoF49wGbla0QC3qNBHtTq7JOOUO6Myu W5b/d/VCdWWHQ4KIE9VFLUtd4LVMq3gqFVOkuSauwHG1gIqYfBc8l45vVm7WWeUO /15juVKfiPZ23Zc5Kh0Gd6EWXNyU7y1B7xqmK24l+ByJBCOCmrF2ZgfAC5YF8ixy 40lbZmQzrd/YtcA0xNOArXRIcPVDr9Qp8T1OAcfZ1FkPMout6FvWNg== =Nln2 -----END PGP SIGNATURE----- From roy at nominet.org.uk Mon Jan 19 11:02:22 2009 From: roy at nominet.org.uk (Roy Arends) Date: Mon, 19 Jan 2009 12:02:22 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> Message-ID: Rickard Bondesson wrote on 01/19/2009 11:58:59 AM: > OK, it seems like we have reached a decision after multiple email > conversations and Jabber chatting. > > Meeting in Amsterdam > Mon 9th Feb. > Host: NLNetLabs Thanks Rickard. I think this is a better alternative to Oxford than meeting at LHR. If folks can give an (estimated) arrival time at NLNetLabs, I know what time to catch the train. Regards, Roy Arends Sr. Researcher Nominet UK From rick at openfortress.nl Mon Jan 19 11:05:40 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 19 Jan 2009 11:05:40 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <69830D4127201D4EBD146B904119971880B24F@EXCHANGE.office.nic.se> References: <20090117221800.GA5422@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B24F@EXCHANGE.office.nic.se> Message-ID: <20090119110540.GA17093@phantom.vanrein.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Rickard, > Is it possible to add a security level to each component of the data flow diagram (DFD)? White/black/grey meaning that the incoming data/resource is trusted/untrusted/somewhat-trusted. Useful when evaluating the source code for any security holes. I don't think it is possible to point at whole components and rate their "importantance to security". I think each component could be open to its own forms of attack, just like any line of code could contain a buffer overflow vulnerability. I am working on a security testing approach from another angle, but this is currently too premature to be worth any discussion. Cheers, -Rick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html iD8DBQFJdF5sFBGpwol1RgYRAsdFAJ9MbObU8qVr9D3YBJ/8O/l7Ep/UAwCgmjkQ rlL79ldMHmwLNTIdHKhWpoE= =VdLA -----END PGP SIGNATURE----- From jakob at kirei.se Mon Jan 19 11:11:25 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 19 Jan 2009 12:11:25 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> Message-ID: On 19 jan 2009, at 11.58, Rickard Bondesson wrote: > Meeting in Amsterdam > Mon 9th Feb. > Host: NLNetLabs thanks richard. flight booked GOT-AMS, I'll arrive in Amsterdam 08:05. returning back 20:55, so there's plenty of time to meet for me all day. jakob From Rickard.Bondesson at iis.se Mon Jan 19 11:32:52 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 19 Jan 2009 12:32:52 +0100 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: References: <69830D4127201D4EBD146B904119971880B208@EXCHANGE.office.nic.se> <49732D52.8090206@NLnetLabs.nl> <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> Message-ID: <69830D4127201D4EBD146B904119971880B25B@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > thanks richard. > flight booked GOT-AMS, I'll arrive in Amsterdam 08:05. > returning back 20:55, so there's plenty of time to meet for > me all day. Patrik and I will arrive in Amsterdam 09.35 and will be returning 19.20. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXRk5OCjgaNTdVjaAQgSFQf+PBfAJU8ULoPudFh3AZIdK5YjyAA1e7in PA4RsZ+gHQFTj7Db5nIroSye+OHZ3n+oWEujDJYeCOYpyuzfUHgns0IcY3A/7HLm 3v88YA1ueGfgoR6Zy8J5PuxY+h8Yw/tm1o53a3voDGvntV6IJ32avblMShK5frcY mkkRjIYrFxWmBLUo4Yw8bqDjMIYJ09avGGqKvFROVLNtSMpdCdJRxLXCKtfvXT/r 9FQ2c7LAKq5RjKkdQoVIvxIR8BOa8u8Lf+NHMGP+GNz3f8a5ZAfUvu3wpACWLeVO yava2oDTNTUadFnp3VZhd+/Pcb2hry3PAJ8M8B833mD/JQD0htOylg== =MOYh -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Mon Jan 19 12:38:28 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 19 Jan 2009 12:38:28 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B25B@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 19/01/2009 11:32:52: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > thanks richard. > > flight booked GOT-AMS, I'll arrive in Amsterdam 08:05. > > returning back 20:55, so there's plenty of time to meet for > > me all day. > > Patrik and I will arrive in Amsterdam 09.35 and will be returning 19.20. Sion Lloyd and I will be staying overnight on Sunday and flying back Monday evening. (Sion will be working on signing .uk and with John Dickinson on the KASP component.) Two questions: a) What the address of the place at which the meeting will be held - will it be NLNetLabs's office? b) Can anyone recommend a nearby hotel? Stephen From Stephen.Morris at nominet.org.uk Mon Jan 19 15:01:44 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Mon, 19 Jan 2009 15:01:44 +0000 Subject: [Opendnssec-develop] KASP Software Message-ID: I had an action from the teleconference to publish more details about KASP. Attached is a documenting describing how to use "ksm", the KASP key management software. The latest version of the software can be found at http://download.nominet.org.uk/KASP/ksm_20090119.tar.gz. ksm implements the algorithm outlined in the attached Internet draft that John Dickinson, Johan Ihren and I are writing. This is still very much work in progress, and I am currently updating it with the results of a recent discussion between the three of us and comments from other parties. However, don't let that put you off: if you have any comments, please don't hesitate to let me know. (To avoid side-tracking OpenDNSSEC discussions, I would suggest that these be off-list - the aim is to submit the draft to dnsop at the end of the month for public comment.) Stephen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ksm_overview.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-morris-dnsop-dnssec-key-management-00.txt URL: From rick at openfortress.nl Mon Jan 19 22:12:42 2009 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 19 Jan 2009 22:12:42 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <69830D4127201D4EBD146B904119971880B24F@EXCHANGE.office.nic.se> References: <20090117221800.GA5422@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B24F@EXCHANGE.office.nic.se> Message-ID: <20090119221242.GA22738@phantom.vanrein.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, > The DFD is essentially a more detailed description on the Signer Engine > with its surrounding. Yes, that is the idea. I wanted to get down to a bit more detail. > Any comments by the Signer Engine development team? Does this conform > to your mindset? To help with answering that question, I've added a bunch of other diagrams documenting parts of the Signer Engine: * Queue and QueuedZone information, central to the synchronisation constructs (basically, databasish transaction serialisation per zone) * Message charts for - IXFR processing (a bit early, but it's simpler than AXFR!) - AXFR processing - Zone re-signing - Key rollover As before, you can find the collection on my website: http://openfortress.nl/tmp/opendnssec/ As before, all these are merely proposals, in an attempt to get some discussion going on the overall structure. If anyone has other ideas s/he is welcome to speak up. It's that kind of design-level debate I'm after. I propose going over diagrams like these during our face2face meeting in Amsterdam. I think such diagrams are useful communication vehicles. Hope this helps, With regards, Rick van Rein OpenFortress -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html iD8DBQFJdPrYFBGpwol1RgYRAqIAAJ9VxEvWIlIRTjwnM8I1PP2R1VN5hACdG/em eSMaOf8pPFSwy+RAgh6Exxk= =/7ce -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Tue Jan 20 11:43:20 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 20 Jan 2009 12:43:20 +0100 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <20090117221800.GA5422@phantom.vanrein.org> References: <20090117221800.GA5422@phantom.vanrein.org> Message-ID: <15C2F97D-66B7-4E72-83A2-B5620DAE9D53@NLnetLabs.nl> On Jan 17, 2009, at 11:18 PM, Rick van Rein wrote: > Hello, > > I've taken the liberty of drawing up a Use Case diagram, describing > OpenDNSSEC as it interacts with its environment. This can be found > on a working page with OpenDNSSEC design documents: > > http://openfortress.nl/tmp/opendnssec/ > > Comments and updates are welcome. The whole idea of making these > design documented is to check if we have the same mindset. If you > see anything "funny" you should therefore speak up :) > > I also drew up Message Sequence diagrams for the Signer, and will > digitise those soon. > > Unless I am mistaken, this scheme looks to relate more to version 2 than to version 1 of what we set out to develop. I thought we agreed to keep focus on version 1 and defer discussion about version 2 elsewhere.... (it is not that I am not interested in this part but we need to focus energy) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From rick at openfortress.nl Tue Jan 20 12:55:39 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 20 Jan 2009 12:55:39 +0000 Subject: [Opendnssec-develop] Project plan In-Reply-To: <69830D4127201D4EBD146B904119971880B1D0@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B1D0@EXCHANGE.office.nic.se> Message-ID: <20090120125539.GC30109@phantom.vanrein.org> Hello Rickard, > Here is my first draft on the project plan. Still missing some peaces like > a more detailed time plan, since we need to plan the components a little > bit more first. I finally found the time to read your setup towards a project plan. Thanks for the effort, first of all -- and here follows some constructive feedback. Background, 2nd par: You suggest that DNS is leaking _because_ it has been araound for many years. It may be better to suggest that it was conceived in a time when security was not a design issue for internet protocols. 3rd par: ...with the help of public-key cryptology: s/cryptology/cryptography/ (cryptology is more general, including attacks, which adds nothing to what you are saying here) is more general, including attacks, which adds nothing to what you are saying here) 1.4 Goals -> I would like to mention cryptographic USB-style tokens and smart cards as well, because they cover a low-price alternative for those who manage small domains. (I remark that this will introduce a number of challenges, as mentioned on the list before: the need to establish a secure source of timing, and lack of abundant space for key storage.) 3.1 Protocol Compliance -> I am not wholly convinced that _generating_ RFC 5011 is a good idea, but _accepting_ it certainly is. Also, standards for plain DNS and a list of extensions would be good to include here. 3.7 I/O of zone data: I am assuming TSIG is based on a pre-shared key. It is good to add that, as it squashes questions about TKEY and SIG(0) which are probably out-of-place here, given the fixed relationships with slave name servers. I have not found a note saying that we are assuming fixed relations with name servers, both for incoming and outgoing DNS traffic. 6. Resource plan: Rogier Spoor is actually not available on the mailing list; he is on a very long holiday. 7. Time plan: You did not mention the project parts that finished, at least to my understanding: SoftHSM, Market Study. Also, it would be good to have a steep deadline for the website. I really think that could use (quite) some work. Remember Roland's mail, where he told us that parties are walking out on us because the website lacks detail -> in casu, RIPE NCC. When told about what was going on they suddenly became enthousiastic. We need a proper website, guys! 8.1 "No similar OpenSource project available" -> bind9 is moving and has recently added PKCS #11 interfacing as well as DDNS signing. They also included ZKT to smoothen signing in a cronjob (anyone tried bind9's version of ZKT yet? The separate download works well for me.) 8.3 Risk management -> 6, drawing conclusions on decisions is your responsibility, Rickard. At least, that's what project management means in my mind, and it's also what we spoke of in the telephone conference. Of course, it shall be by voting, but you're the one responsible for getting the vote and spreading the results of it. 9.4 I am currently writing a few articles about DNSSEC in the Dutch InfoSecurity.nl magazine. I mentioned the SURFnet white paper in episode 2. We are still talking about an episode 3, in which there will be more howto-talk, and at which stage OpenDNSSEC would come into view. 9.6 Final report -> I propose writing it as part of the acceptance phase. Nobody will be motivated to write it afterwards. 9.7 I don't mind any interpretation of the wiki, but I keep hearing two things: 1. The wiki is for final results only 2. The wiki is a place for discussion and voting Both are fine with me, but it's not clear right now. Hope this helps! -Rick From Stephen.Morris at nominet.org.uk Tue Jan 20 15:09:16 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 20 Jan 2009 15:09:16 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <15C2F97D-66B7-4E72-83A2-B5620DAE9D53@NLnetLabs.nl> Message-ID: Olaf Kolkman wrote on 20/01/2009 11:43:20: > I thought we agreed to keep focus on version 1 and defer discussion > about version 2 elsewhere.... ... in which case can I submit the following as the use-cases we should focus on for phase 1a? Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: ZoneFileUseCases.pdf Type: application/pdf Size: 94332 bytes Desc: not available URL: From olaf at NLnetLabs.nl Tue Jan 20 15:54:46 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 20 Jan 2009 16:54:46 +0100 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: References: Message-ID: <8D8869BB-794D-41A8-94A6-15E15301B7B9@nlnetlabs.nl> On Jan 20, 2009, at 4:09 PM, Stephen.Morris at nominet.org.uk wrote: > Olaf Kolkman wrote on 20/01/2009 11:43:20: > >> I thought we agreed to keep focus on version 1 and defer discussion >> about version 2 elsewhere.... > > ... in which case can I submit the following as the use-cases we > should > focus on for phase 1a? > I could imagine two different roles: A Zone Manager (responsible for zone content) and a Key Manager (or security officer) responsible for keys and key policies. I would treat those separately as those two roles may not be assigened to the same actor. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From Rickard.Bondesson at iis.se Tue Jan 20 16:08:53 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Tue, 20 Jan 2009 17:08:53 +0100 Subject: [Opendnssec-develop] Our web page Message-ID: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I started to day to clean up on our web page and added some more information. More works needs to be done, but it is a start. Comments? Think it is Jakob who gives editing privileges on the wiki. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXX3FeCjgaNTdVjaAQhtwgf/WVkiATbMIKokuuLFTC3JS6AELaG2x8xN 4ZCSKO7RFOb13RtbVmVlJzsL72a8//lbPBq5od/clmjixNliPVU2SKBPgdla2p0z KqgHDnXfveQl8Iap7jfgcfZtrmxHCG6VXGyhdSfQ/9B2xV+8IgHC+weFBrEu8Vok Y9KMfCdqsUQWTDfgou5sBBvk6mXY4P7sv8/VbqpN7FdPoycqR4RfQEqgLDOxR6X8 dxRFu4VM8K+aFntM5AsOVV2Cqj8P92OhZx3X232g19axXWHAIogwf+6vR7TsJxrA 3TDDHTpP52GhB7q8Kw0mbN9zlDZp6QKqcZbeX25TQXJ26AsT16+AeQ== =/LJd -----END PGP SIGNATURE----- From roland.vanrijswijk at surfnet.nl Tue Jan 20 16:12:11 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 20 Jan 2009 17:12:11 +0100 Subject: [Opendnssec-develop] Our web page In-Reply-To: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> Message-ID: <4975F7DB.6050207@surfnet.nl> Hi Rickard, Good work, at least there is some more concrete information available now. Maybe 'work in progress' is a bit too general, you could consider 'currently under development, see time-line' and then link to the time line in the project plan. Best regards, Roland Rickard Bondesson wrote: > Hi > > I started to day to clean up on our web page and added some more information. More works needs to be done, but it is a start. Comments? Think it is Jakob who gives editing privileges on the wiki. > > // Rickard ------------------------------------------------------------------------ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Stephen.Morris at nominet.org.uk Tue Jan 20 16:26:51 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 20 Jan 2009 16:26:51 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: <8D8869BB-794D-41A8-94A6-15E15301B7B9@nlnetlabs.nl> Message-ID: Olaf Kolkman wrote on 20/01/2009 15:54:46: > > On Jan 20, 2009, at 4:09 PM, Stephen.Morris at nominet.org.uk wrote: > > > Olaf Kolkman wrote on 20/01/2009 11:43:20: > > > >> I thought we agreed to keep focus on version 1 and defer discussion > >> about version 2 elsewhere.... > > > > ... in which case can I submit the following as the use-cases we > > should > > focus on for phase 1a? > > > > I could imagine two different roles: A Zone Manager (responsible for > zone content) and a Key Manager (or security officer) responsible for > keys ... That's a good point. > ... and key policies. This implies a further use-case, "Edit Key Policies". Are there any others? Stephen From olaf at NLnetLabs.nl Tue Jan 20 19:05:35 2009 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 20 Jan 2009 20:05:35 +0100 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: References: Message-ID: On Jan 20, 2009, at 5:26 PM, Stephen.Morris at nominet.org.uk wrote: >> ... and key policies. > > This implies a further use-case, "Edit Key Policies". Are there any > others? Initiate emergency role-over Also do you want to keep "the parent" out of the set of <>? At some point there may be DS or NS changes. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam NB: The street at which our offices are located has been renamed to the above. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jakob at kirei.se Tue Jan 20 21:53:52 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 20 Jan 2009 22:53:52 +0100 Subject: [Opendnssec-develop] Our web page In-Reply-To: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> Message-ID: <642AA5F6-17E2-40E7-8EC7-4308DC7FF05B@kirei.se> thanks you rickard for doing this. extra points for keeping the structure of the wiki - I appreciate it! jakob From Rickard.Bondesson at iis.se Wed Jan 21 10:01:55 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 21 Jan 2009 11:01:55 +0100 Subject: [Opendnssec-develop] Our web page In-Reply-To: <4975F7DB.6050207@surfnet.nl> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> <4975F7DB.6050207@surfnet.nl> Message-ID: <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Good work, at least there is some more concrete information > available now. Maybe 'work in progress' is a bit too general, > you could consider 'currently under development, see > time-line' and then link to the time line in the project plan. I think that we should add Trac Roadmap and Trac Ticket to the wiki. Jakob? Then we can set up the time plan more flexible and have the possibility of follow ups. Do you agree that this is a good solution and better to have than text format in the wiki or an attached PDF? I will start doing the work breakdown structure mean vile. I think that the intent with the wiki is to have us post information on it in a structured way. Remember that our web page can be viewed by everyone on the Internet. We also have a source code repository. The intent is that the code we produce are checked in here. Still missing code from the signer engine and KASP. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXbyk+CjgaNTdVjaAQgBoAgAhhQdw7ApeODyGIJeR/JfVrfZPhVTQOYu RSG25e4nLunZze7y64FAGVUDRzmsEAjwNZNRgS1z74aDs6103KWU/xQuAzvX2Yny i1jcbPBSQ6pY/+5HEZiv1UztYAkWKfWaIG3DGCsx7onNxj66UYa4+T/dJPL9i5Q9 HkqcwVFnlNCBHhdv1uovNhPbncTwb018gRwZwxhAgpfF4g1VbLYKGb+eVNNE3tSO UHcwEURw+3hfuwsIidQQO5+8LD5jQUxOo4FN4JmOo0YYhQrXm02uTxnX8bcM69Wm wdMLC6AczGA5xdYdpDcsMvH9Saxxv089SqdBavKFPO6N5T5b68lV/g== =joRs -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Wed Jan 21 12:26:41 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 21 Jan 2009 12:26:41 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: Message-ID: Olaf Kolkman wrote on 20/01/2009 19:05:35: > > On Jan 20, 2009, at 5:26 PM, Stephen.Morris at nominet.org.uk wrote: > > >> ... and key policies. > > > > This implies a further use-case, "Edit Key Policies". Are there any > > others? > > Initiate emergency role-over That is what I meant by the use case "Emergency Key Rollover". > Also do you want to keep "the parent" out of the set of <>? At > some point there may be DS or NS changes. In fact, for each key rollover there are two use-cases, one for rolling the ZSK (which does not interact with the parent) and one for rolling the KSK (which does). I'll update the diagram accordingly. Stephen From Stephen.Morris at nominet.org.uk Wed Jan 21 12:32:41 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Wed, 21 Jan 2009 12:32:41 +0000 Subject: [Opendnssec-develop] Face-to-Face February In-Reply-To: <69830D4127201D4EBD146B904119971880B25A@EXCHANGE.office.nic.se> Message-ID: "Rickard Bondesson" wrote on 19/01/2009 10:58:59: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > OK, it seems like we have reached a decision after multiple email > conversations and Jabber chatting. > > Meeting in Amsterdam > Mon 9th Feb. > Host: NLNetLabs The above just says "Host". Can I confirm then that the meeting is at NLNetLabs's office at Science Park 140, 1098 XG Amsterdam Also, could I repeat my request for hotel recommendations? Thanks Stephen From jakob at kirei.se Wed Jan 21 18:44:41 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 21 Jan 2009 19:44:41 +0100 Subject: [Opendnssec-develop] Our web page In-Reply-To: <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> <4975F7DB.6050207@surfnet.nl> <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> Message-ID: <5CD0B6F7-0F9A-4F86-BB60-3EBB26CB4873@kirei.se> On 21 jan 2009, at 11.01, Rickard Bondesson wrote: > I think that we should add Trac Roadmap and Trac Ticket to the wiki. > Jakob? Then we can set up the time plan more flexible and have the > possibility of follow ups. Do you agree that this is a good solution > and better to have than text format in the wiki or an attached PDF? > I will start doing the work breakdown structure mean vile. sure, works for me. it is already enabled, but I guess you want it for anonymous users, right? > I think that the intent with the wiki is to have us post information > on it in a structured way. Remember that our web page can be viewed > by everyone on the Internet. yes, the information on the wiki is always public - even work in progress. jakob From Rickard.Bondesson at iis.se Thu Jan 22 12:58:23 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Thu, 22 Jan 2009 13:58:23 +0100 Subject: [Opendnssec-develop] Our web page In-Reply-To: <5CD0B6F7-0F9A-4F86-BB60-3EBB26CB4873@kirei.se> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> <4975F7DB.6050207@surfnet.nl> <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> <5CD0B6F7-0F9A-4F86-BB60-3EBB26CB4873@kirei.se> Message-ID: <69830D4127201D4EBD146B904119971880B3EA@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ok. Now we have a roadmap with milestones. Each milestone has tickets connected to it. We need to add more tickets to the system, so we know what needs to be done for each component. We are also waiting for the update on the architecture from Roy and Jakob. Everyone should get an account on the wiki and start adding information. You can get that from Jakob. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSXhtb+CjgaNTdVjaAQhVmwf9HAafbQTBsktXy3ggHs+LcT8+jIlWZ7jr vpL7JKhqSjhgmL5Qw0wrKN4mMIbjKQi4bXxtsKyhIky5vV/h4aq3Pm499v1IsVrc /Xs04KCYv48UycO7dWUMw8RKYP34v4UBLNRYUnF2hf/8Tr21EVxtmX9eFDQDrxdV IOA//cWq+RNICtBRdA1gXW45DO3K9QzBEE30UphTOPChwJg5g/40sbzHKfCEEvHi OQCdYgaxfrAUClqLpvG1xx4R5kmza2B3Y048qi5Z7LqoTyH1XL748WYP3z+gETJP pbWAUFI6jP4wcpbKkjDN4MjOdMuv+rYVNtVBvftU0VjqhkRxySKs/A== =s8+e -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Jan 23 11:13:29 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 23 Jan 2009 12:13:29 +0100 Subject: addition to code repos (was Re: [Opendnssec-develop] Our web page) In-Reply-To: <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B33A@EXCHANGE.office.nic.se> <4975F7DB.6050207@surfnet.nl> <69830D4127201D4EBD146B904119971880B365@EXCHANGE.office.nic.se> Message-ID: <4979A659.5060100@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: > > We also have a source code repository. The intent is that the code we produce are checked in here. Still missing code from the signer engine and KASP. > I've added a signer_tools directory, containing a number of small tools that together can sign a zone (optinally with pkcs11). This might actually be very close to the pipeline signer as Jakob originally requested from me way back ;) Some description in the README file. 'open issues': Only supports RSA_SHA1 atm (rest is on the todo) No way to put glue back yet Apart from the test script, there is atm no script/tool to tie them all together, but testing is very welcome. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl5plgACgkQ4nZCKsdOncW/EQCgqdErkpxJdXqEMGNGgFwNVGg+ amIAoK0gWj6ztWBtmz7I4/GOyEqWhwOF =Dzlo -----END PGP SIGNATURE----- From jakob at kirei.se Fri Jan 23 16:40:31 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 23 Jan 2009 17:40:31 +0100 Subject: [Opendnssec-develop] wiki & svn server maintenance Message-ID: greetings, I will do some software update on the wiki server this weekend (probably sunday). {svn,www}.opendnssec.{com,net,org,se} will probably be unreachable during this time. a new SSH fingerprint will appear after the change, but will be published in DNS. have a nice weekend, jakob From jelte at NLnetLabs.nl Fri Jan 23 16:52:20 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 23 Jan 2009 17:52:20 +0100 Subject: hotels (was Re: [Opendnssec-develop] Face-to-Face February) In-Reply-To: References: Message-ID: <4979F5C4.7040809@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen.Morris at nominet.org.uk wrote: > Also, could I repeat my request for hotel recommendations? > Yeah, sorry for not replying earlier, we were all waiting for someone else to have any recommendations. Truth is, we never stay in hotels there, so we don't really know :) I've been asking around a bit, and I think the closest ones to our office are NH Tropen http://www.nh-hotels.nl/nh/nl/hotels/nederland/amsterdam/nh-tropen.html or Hotel Arena http://www.hotelarena.nl Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl59cQACgkQ4nZCKsdOncUZ3QCgzPnogET9L3xzqLuCBF7z8may uDIAoIegW10NkhLBoNZO8y9DI9/dKyDS =Fqql -----END PGP SIGNATURE----- From jakob at kirei.se Sun Jan 25 10:04:54 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Sun, 25 Jan 2009 11:04:54 +0100 Subject: [Opendnssec-develop] Re: wiki & svn server maintenance In-Reply-To: References: Message-ID: <524531B8-9721-45F9-BBD0-733BBF8DC5E2@kirei.se> On 23 jan 2009, at 17.40, Jakob Schlyter wrote: > I will do some software update on the wiki server this weekend > (probably sunday). > {svn,www}.opendnssec.{com,net,org,se} will probably be unreachable > during this time. > > a new SSH fingerprint will appear after the change, but will be > published in DNS. maintenance is now complete. - trac is now v0.11, running under Apache 2.2 and mod_python - subversion is now v1.5.1 please report and problems to me and I'll try to resolve them as soon as possible. jakob From Rickard.Bondesson at iis.se Mon Jan 26 08:25:44 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 26 Jan 2009 09:25:44 +0100 Subject: hotels (was Re: [Opendnssec-develop] Face-to-Face February) In-Reply-To: <4979F5C4.7040809@NLnetLabs.nl> References: <4979F5C4.7040809@NLnetLabs.nl> Message-ID: <69830D4127201D4EBD146B904119971880B485@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jelte, you were also trying to book a meeting room. How is that going? So we know where the meeting venue is. // Rickard > -----Ursprungligt meddelande----- > Fr?n: Jelte Jansen [mailto:jelte at NLnetLabs.nl] > Skickat: den 23 januari 2009 17:52 > Till: Stephen.Morris at nominet.org.uk > Kopia: Rickard Bondesson; Opendnssec-develop at lists.opendnssec.org > ?mne: hotels (was Re: [Opendnssec-develop] Face-to-Face February) > > * PGP Signed by an unknown key > > Stephen.Morris at nominet.org.uk wrote: > > > Also, could I repeat my request for hotel recommendations? > > > > Yeah, sorry for not replying earlier, we were all waiting for > someone else to have any recommendations. Truth is, we never > stay in hotels there, so we don't really know :) > > I've been asking around a bit, and I think the closest ones > to our office are > > NH Tropen > http://www.nh-hotels.nl/nh/nl/hotels/nederland/amsterdam/nh-tr open.html > > or > > Hotel Arena > http://www.hotelarena.nl > > Jelte > > * Unknown Key > * 0xC74E9DC5(L) > -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSX1ziOCjgaNTdVjaAQizlQf/cLrsXMrnuCr+NZOltw5lDVYERxN0hmeV PyMHatP8fnV948tp5cyARyVW4TZElxX0EiThR4TpPGw5CXLBPDoXVXjPiA8VFAXi XPp8U/k2Kh7WErD9k9pLsj5gg0KFVW4jV1ubFNM+eX8U4bzZRf9ivJR3Xqda5DbU v4ptb/PWUprIOGG7HqtBkf/ezFxUJrWDHT2b4jOyOBSy4HdX5C6L+ZPsw7/LTxTD Osfx4Np5IvXRo6YR46CuchBeHCgXDbUxFdRDpnnHTDD3m1QuuK1UTlWIcgOYRl/N g9sO5zTc4sSZlhnEVphbVQPe2VNLslnoWaXJuXuRhypNhixemf+DmA== =jyJj -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Mon Jan 26 10:54:32 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Mon, 26 Jan 2009 11:54:32 +0100 Subject: hotels (was Re: [Opendnssec-develop] Face-to-Face February) In-Reply-To: <69830D4127201D4EBD146B904119971880B485@EXCHANGE.office.nic.se> References: <4979F5C4.7040809@NLnetLabs.nl> <69830D4127201D4EBD146B904119971880B485@EXCHANGE.office.nic.se> Message-ID: <497D9668.7030002@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: > Jelte, you were also trying to book a meeting room. How is that going? So we know where the meeting venue is. > yes, I have reserved a room for the entire day at the Matrix II building, just across the street from our building (which is Matrix I). The full address is Science Park 400 Room 1B I have not seen the room myself yet, but I am told there is an internet connection. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl9lmgACgkQ4nZCKsdOncXsnQCbBwmYzboCoa1mrNpV1BOgINfX /gMAn1V6bdQjroMmW9pC7OYQvWbjYwVF =E2hP -----END PGP SIGNATURE----- From Rickard.Bondesson at iis.se Mon Jan 26 13:02:52 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Mon, 26 Jan 2009 14:02:52 +0100 Subject: [Opendnssec-develop] Call for meeting topics, 9th Feb Message-ID: <69830D4127201D4EBD146B904119971880B4C0@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I am making a call for meeting topics. Here are some thoughts by me. Please reply with more topics and a description of them. I will arrange an agenda based on this and post it back to the list. // Rickard ********* * Draft * ********* Who will write minutes? - - Decide who will write minutes during this meeting. Marketing plan - - Use Cases Discuss the use cases presented on the mailing list. Do we need to fulfil all of the use cases? What do we need to fulfil the individual use case? - - Market study What experiences do we have from the market? Do we need to do a study of what our potential users might want? How should such study be performed? Who should we ask? - - Marketing of our product Do we want our product to be noticed by other parties than us? Who would that be? How do we reach them? System design for phase 1 and 2 - - General architecture Do we agree on the general concept? Is there something we would like to change? - - Components Can we specify the components any more? Any requirements? - - Data flow diagram Discuss how the data is flowing through the architecture. - - API between the components How should each component talk to its neighbours? Discussion about each component - - What has been done? - - What needs to be done? - - How much time does each subtask need? - - Testing? OpenDNSSEC v1.0 and v.1.1 - - How should we fit everything together? - - Testing? Comparison of HSM:s - - What information do we want on the wiki? A more detailed comparison? A how-to? Configurations? Recommendations? About the project - - Trademark How should we protect our trademark? - - Packaging the code How should our program/code be published? Debian/RPM/?? Next meeting - - How and when? -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSX20fOCjgaNTdVjaAQiGbgf/eJhb8AzCyoGnJLwM8TiDvyt74GzcE7xo vnVG/KqyMUw2RXBA39/C+tDpOO2z/VSdYmg6lG2rE55DoaO5dHwKYtG1iV0emz3A wsvcB+z1VOvZpWgK7ggNdkWpo7h8T44UVFyVPnz8NLS48me50+tVYJrWnu2d8FCZ 15HwVCA8IgwaT1aQWYgpjvEkGqAPOllCFZZ+tDfzhUiGf2zf2HSaOKpBtFq/P9Dh g/k5oMX/4VSN2izNMEhZIs3DjYTz7E9U02n8n2wUXGf+MrbwrLDS8iYdgnfNwzLd Kqius+O+22GaR2VqDCzhNSszVYObCSUSB9rFzscMZiVOHC+EvC6mhw== =wkrd -----END PGP SIGNATURE----- From jakob at kirei.se Mon Jan 26 19:59:08 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 26 Jan 2009 20:59:08 +0100 Subject: [Opendnssec-develop] pkcs11.h license Message-ID: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> someone dropped me an email telling me that SoftHSM's pkcs11.h isn't GPL-compatible: http://www.opendnssec.se/browser/trunk/softHSM/src/pkcs11.h now, we have a BSD-license, but if someone would like to use it in a GPL context we should perhaps look at: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=30&root=Scute&view=markup rickard; could check if it would be possible to get rid of the RSA license by using the file above? (and the same for other files) jakob From roland.vanrijswijk at surfnet.nl Tue Jan 27 08:14:49 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 27 Jan 2009 09:14:49 +0100 Subject: [Opendnssec-develop] pkcs11.h license In-Reply-To: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> References: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> Message-ID: <497EC279.4080904@surfnet.nl> Hi Jakob, Did this person motivate why the PKCS #11 headers aren't GPL compatible? Because I've done some searching and had a good look at the licensing and I don't think this is the case. There are PKCS #11 _modules_ that are not GPL compatible (a lot of information can be found on this), but the PKCS #11 headers themselves aren't necessarily GPL incompatible. I would advise against using third party PKCS #11 headers simply for this reason, and it is debatable whether typing out the header file yourself is not a violation of RSA's license. Just my 2 cents... Cheers, Roland Jakob Schlyter wrote: > someone dropped me an email telling me that SoftHSM's pkcs11.h isn't > GPL-compatible: > > http://www.opendnssec.se/browser/trunk/softHSM/src/pkcs11.h > > now, we have a BSD-license, but if someone would like to use it in a GPL > context we should perhaps look at: > > http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/pkcs11.h?rev=30&root=Scute&view=markup > > > rickard; could check if it would be possible to get rid of the RSA > license by using the file above? (and the same for other files) > > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jakob at kirei.se Tue Jan 27 08:23:54 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 27 Jan 2009 09:23:54 +0100 Subject: [Opendnssec-develop] pkcs11.h license In-Reply-To: <497EC279.4080904@surfnet.nl> References: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> <497EC279.4080904@surfnet.nl> Message-ID: On 27 jan 2009, at 09.14, Roland van Rijswijk wrote: > Did this person motivate why the PKCS #11 headers aren't GPL > compatible? > Because I've done some searching and had a good look at the licensing > and I don't think this is the case. There are PKCS #11 _modules_ that > are not GPL compatible (a lot of information can be found on this), > but > the PKCS #11 headers themselves aren't necessarily GPL incompatible. nope. > I would advise against using third party PKCS #11 headers simply for > this reason, and it is debatable whether typing out the header file > yourself is not a violation of RSA's license. I agree, we should - if possible - be independent of other license other than a pure BSD license. jakob From roland.vanrijswijk at surfnet.nl Tue Jan 27 08:36:36 2009 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 27 Jan 2009 09:36:36 +0100 Subject: [Opendnssec-develop] pkcs11.h license In-Reply-To: References: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> <497EC279.4080904@surfnet.nl> Message-ID: <497EC794.1020808@surfnet.nl> Hi Jakob, Jakob Schlyter wrote: > On 27 jan 2009, at 09.14, Roland van Rijswijk wrote: > >> Did this person motivate why the PKCS #11 headers aren't GPL compatible? >> Because I've done some searching and had a good look at the licensing >> and I don't think this is the case. There are PKCS #11 _modules_ that >> are not GPL compatible (a lot of information can be found on this), but >> the PKCS #11 headers themselves aren't necessarily GPL incompatible. > > nope. As the oracle said: beware of Greeks bearing gifts :-) Seriously though, we should be wary of these kinds of remarks. Although every outside package that is used should be vetted by taking a good look at the license this shouldn't be overdone; if there are good reasons why something that isn't GPL compatible need to be used then so be it -- I'm very much of the opinion that one should use 'the right tool for the right job'. As long as it doesn't violate OpenDNSSEC's license (BSD, right?). Having said that, some care should be taken to try and stay GPL compatible if possible, but in my opinion, this should not be the holy grail. >> I would advise against using third party PKCS #11 headers simply for >> this reason, and it is debatable whether typing out the header file >> yourself is not a violation of RSA's license. > > I agree, we should - if possible - be independent of other license other > than a pure BSD license. I think we agree. The RSA license is very BSD-ish (you can use it, just mention where you got it). Cheers, Roland. -- -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rick at openfortress.nl Tue Jan 27 08:38:26 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 27 Jan 2009 08:38:26 +0000 Subject: [Opendnssec-develop] pkcs11.h license In-Reply-To: References: <0E628952-376B-406D-8D5F-C0C688581479@kirei.se> <497EC279.4080904@surfnet.nl> Message-ID: <20090127083826.GA32586@phantom.vanrein.org> Hi, > >Did this person motivate why the PKCS #11 headers aren't GPL > >compatible? > > nope. It's a non-issue. It's okay to refer to RSA with their prescribed thank-you (that's simply credit where credit is due) and other than that there are no problems with this license. RSA clearly wants this header file to be used, instead of paid for. Licensing issues have a way of causing fear/uncertainty/doubt but since this license is wide-open we need not waste our time on that. Cheers, -Rick From rick at openfortress.nl Tue Jan 27 08:45:20 2009 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 27 Jan 2009 08:45:20 +0000 Subject: [Opendnssec-develop] face2face agenda: design diagrams Message-ID: <20090127084520.GB32586@phantom.vanrein.org> Hello Rickard, A proposal for the face2face agenda, if I may. I would like to reserve (a lot of) time to discuss diagrams for the OpenDNSSEC system. I've led enough discussions on object designs to have learnt how insightful it is to discuss them. Usually, an open discussion will bring up issues about the boundaries of a concept as it is caught in the diagramming blocks, thus leading to better insight in the topic at hand. One way of conducting such discussion is to have the diagrams presented by their authors, and having the others fire questions at them. If a number of alternative designs exist, they are best presented at the same time and interactively brought in line with each other. Hope this helps, -Rick From Rickard.Bondesson at iis.se Tue Jan 27 08:49:22 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Tue, 27 Jan 2009 09:49:22 +0100 Subject: [Opendnssec-develop] face2face agenda: design diagrams In-Reply-To: <20090127084520.GB32586@phantom.vanrein.org> References: <20090127084520.GB32586@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I would like to reserve (a lot of) time to discuss diagrams > for the OpenDNSSEC system. I've led enough discussions on > object designs to have learnt how insightful it is to discuss > them. Usually, an open discussion will bring up issues about > the boundaries of a concept as it is caught in the > diagramming blocks, thus leading to better insight in the > topic at hand. > > One way of conducting such discussion is to have the diagrams > presented by their authors, and having the others fire > questions at them. If a number of alternative designs exist, > they are best presented at the same time and interactively > brought in line with each other. Hi Good, will add it as a topic. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSX7KkuCjgaNTdVjaAQiPbgf/SJUeXt+X1wMs5+t4yIrhyOZbypH17qlY HhZNvjNNVHGT36kTm5F819AYyBxV9qi/unxrQNoXMhEeHdo3aCKpW11dUXLKT6YK Nzc8ACm5yYaqfMXfWm5WbIatZyflRCunTtPnkVHv73fePyRyy8JK1dR6zRsjd6js ESp1BJbUv8UyB2vJijNwNltQnNn/ImHkAR3cuIVTVDhO7KhWPePBBqknd0fpNi8w w8Wnc/wbo+9Cn+XXQK7LmulxPbmKVskv67fwdkbHRmdNVGSKNAhPrT/diwSxotDL TvnoEzJx0McY2oL0hDvDCCYRVP8mLYqUGFRake+LT7Fh23BiAN57Bg== =xFyg -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Tue Jan 27 16:55:51 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Tue, 27 Jan 2009 16:55:51 +0000 Subject: [Opendnssec-develop] Use Case diagram for OpenDNSSEC In-Reply-To: Message-ID: stephen.morris at nominet.org.uk wrote on 21/01/2009 12:26:41: > > Also do you want to keep "the parent" out of the set of <>? At > > some point there may be DS or NS changes. > > In fact, for each key rollover there are two use-cases, one for rolling > the ZSK (which does not interact with the parent) and one for rolling the > KSK (which does). I'll update the diagram accordingly. Done. The updated use-case diagram for phase 1a (zone file signing) can be found at http://download.nominet.org.uk/OpenDNSSEC/ZoneFileUseCases.pdf Stephen From Rickard.Bondesson at iis.se Wed Jan 28 09:56:59 2009 From: Rickard.Bondesson at iis.se (Rickard Bondesson) Date: Wed, 28 Jan 2009 10:56:59 +0100 Subject: [Opendnssec-develop] Newsletter #1 Message-ID: <69830D4127201D4EBD146B904119971880B5E4@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The idea is that I will send a newsletter every second week to the OpenDNSSEC project group. The aim with the newsletter is to summarize the work that has been done so far and what are next on the agenda. * The project The project wiki, www.opendnssec.se, has been updated with new information and is organized in a better way. The wiki software on our server has been upgraded to a newer version. A project plan has been written and published on the wiki. The overall milestones are published on the wiki with their individual subtasks. The work needs to be divided into smaller pieces. E.g. defining what needs to be done in the different components. * Meetings 2009-01-14 Rickard Bondesson, from .SE, was appointed as the project manager. A major topic was our own view of the project. What is OpenDNSSEC? What is it going to do? How should it look like? The meeting was limited to 90 minutes and because of this had we no time to draw any definite conclusions. The reason to this confusion was the lack of well defined information on the project. Roy and Jakob were assigned the task to define the system architecture further more. Read the meeting minutes at: http://www.opendnssec.se/wiki/Meetings/Minutes/2009-01-14 2009-02-09 The next meeting is in Amsterdam. Hosted by NLNetLabs at Science Park 400 (Matrix II building), Room 1B. A call for meeting topics is available on the mailing list. The draft of the agenda will be published shortly. * Use cases We are currently working on the different possible use cases. These will be discussed and further analysed at the Amsterdam meeting. * Data flow diagram Rick has created a data flow diagram based on our discussions and the current available system architecture. This work needs to be discussed and agreed upon by the project group. * Signer Engine The individual components of the Signer Engine are available in the code repository. They are working and can produce DNSSEC records as expected. There still needs something that can tie these components together. * SoftHSM Working code is available in the repository. The work is going as planned. The most visible change is that a compilation of the source code will result in two libraries. One for regular use and one for debugging. The debugging version gives notifications to the system log of the different events, which should help any problem solving. Currently working on detecting any memory leeks. More detailed time plan is available on the wiki. * KASP and KSM KSM (Key and Signature Manager) is a program to implement KASP (Key and Signature Policy). It comprises a database and command-line interface (CLI). KSM implements the algorithm outlined in the Internet draft that John Dickinson, Johan Ihren and Stephen Morris are writing. This is still very much work in progress, and Stephen is currently updating it with the results of a recent discussion. More information needs to be published on the wiki. The latest version of the software can be found at http://download.nominet.org.uk/KASP/ksm_20090119.tar.gz ****************************************** // Rickard Bondesson -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYAr6+CjgaNTdVjaAQhhxwf+KtQ/BSKzi0pOyxO9syur+1KKRF3kmVEX J/glkxPyJNAoAQGdhVKCAHmWnEW3p/hSareU9Ffsv7JBcAeAxdAdCOKzZIsrxhzz RjRqA3WCEed+sZ3gdkb+9SIeWwc13vEgcnJGi9wZz6hp8RocaJSK6WdgstskgzfI JlUhVHo9oyXBA++SS1Gs/Mgpnc7VCwrsaLB4BNDI9SCoG9qflWvU92ZueQt66p2X guTY2fLNW5cNPsBFtLw50s1tww76SN0kZNRKpEkuIv8h5vjekvJ3V7DLPXHKtaZb BnkJBbnVkZXvZ7crA4PvfYcwUKw3Fd26hl8m7Obq/aN81g9fw/r4/g== =a8xg -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Wed Jan 28 10:40:02 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 28 Jan 2009 11:40:02 +0100 Subject: [Opendnssec-develop] Newsletter #1 In-Reply-To: <69830D4127201D4EBD146B904119971880B5E4@EXCHANGE.office.nic.se> References: <69830D4127201D4EBD146B904119971880B5E4@EXCHANGE.office.nic.se> Message-ID: <49803602.8090500@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bondesson wrote: > > * Signer Engine > > The individual components of the Signer Engine are available in the code > repository. They are working and can produce DNSSEC records as expected. > There still needs something that can tie these components together. > for the sake of iterative development of the first version, and since specific interfaces still need to be fleshed out, i would like to suggest that i make the scripts that do that in python (ie. the 'heart' of the engine). The processor-intensive operations are of course still performed by the c code that make the individual components. Do people have problems with that? (this is an open suggestion, with my personal preference; i really like the easy with which you can tie input/output of processes together in python) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmANgIACgkQ4nZCKsdOncXQBACg1lr3ZpPJfhkqb/S4QW4++c71 SmoAoLrnjRf6x3uVAb/9Nu8ELJd2V8rv =ED1Q -----END PGP SIGNATURE----- From Stephen.Morris at nominet.org.uk Thu Jan 29 09:53:03 2009 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 29 Jan 2009 09:53:03 +0000 Subject: [Opendnssec-develop] Choice of scripting language In-Reply-To: <49803602.8090500@NLnetLabs.nl> Message-ID: Jelte Jansen wrote on 28/01/2009 10:40:02: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rickard Bondesson wrote: > > > > * Signer Engine > > > > The individual components of the Signer Engine are available in the code > > repository. They are working and can produce DNSSEC records as expected. > > There still needs something that can tie these components together. > > > > > for the sake of iterative development of the first version, and since specific > interfaces still need to be fleshed out, i would like to suggest > that i make the > scripts that do that in python (ie. the 'heart' of the engine). The > processor-intensive operations are of course still performed by the > c code that > make the individual components. > > Do people have problems with that? (this is an open suggestion, with > my personal > preference; i really like the easy with which you can tie input/output of > processes together in python) > > Jelte The choice of scripting language probably isn't too important, but my impression is that knowledge of the Bourne shell is more widespread than knowledge of python, so the scripts may be understood (and modified?) by a wider audience if written in "sh". Stephen From jelte at NLnetLabs.nl Thu Jan 29 23:59:47 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 30 Jan 2009 00:59:47 +0100 Subject: [Opendnssec-develop] Choice of scripting language In-Reply-To: References: Message-ID: <498242F3.4070402@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen.Morris at nominet.org.uk wrote: >> >> for the sake of iterative development of the first version, and since > specific >> interfaces still need to be fleshed out, i would like to suggest >> that i make the >> scripts that do that in python (ie. the 'heart' of the engine). The >> processor-intensive operations are of course still performed by the >> c code that >> make the individual components. > > The choice of scripting language probably isn't too important, but my > impression is that knowledge of the Bourne shell is more widespread than > knowledge of python, so the scripts may be understood (and modified?) by a > wider audience if written in "sh". > technically, sh != bash, except on linux ;) however, as i had envisioned it, it would do quite a bit more than just call the signer and query the kasp; it would also listen (or query for) changing directives from the kasp, and schedule the automatic resigning operations. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmCQvMACgkQ4nZCKsdOncWNpwCg0oZsdzVkkmRo8sOa1Ya+Ktn8 F5cAoNBlTqMXd230Mve56xR1s/RYm7n5 =QWH1 -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Jan 30 00:05:48 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 30 Jan 2009 01:05:48 +0100 Subject: [Opendnssec-develop] Choice of scripting language In-Reply-To: <498242F3.4070402@NLnetLabs.nl> References: <498242F3.4070402@NLnetLabs.nl> Message-ID: <4982445C.8040505@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jelte Jansen wrote: > Stephen.Morris at nominet.org.uk wrote: >> The choice of scripting language probably isn't too important, but my >> impression is that knowledge of the Bourne shell is more widespread than >> knowledge of python, so the scripts may be understood (and modified?) by a >> wider audience if written in "sh". > > > technically, sh != bash, except on linux ;) > and let me be the first to correct myself, somehow I read an "Again" there, which has mysteriously disappeared from your original message now. Probably has something to do with us constantly adding bashisms to our sh scripts :) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmCRFwACgkQ4nZCKsdOncWNzQCgzUGepHK8JuDQmd2cQGSLDGu+ oCMAn1RACaxHldlM8UMYRwCQXmO4cYVI =x6fW -----END PGP SIGNATURE----- From jakob at kirei.se Fri Jan 30 07:36:27 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 30 Jan 2009 08:36:27 +0100 Subject: [Opendnssec-develop] Choice of scripting language In-Reply-To: References: Message-ID: <5EA0A215-AC09-43A3-8951-EBE24C4E45B2@kirei.se> On 29 jan 2009, at 10.53, Stephen.Morris at nominet.org.uk wrote: > The choice of scripting language probably isn't too important, but my > impression is that knowledge of the Bourne shell is more widespread > than > knowledge of python, so the scripts may be understood (and > modified?) by a > wider audience if written in "sh". if a scripting language is needed, I would recommend something more powerful than bourne-shell. python extensions for kasp and the signer could be developed when needed and used directly from within the language - something bourne-shell can't do. jakob From rick at openfortress.nl Fri Jan 30 09:05:41 2009 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 30 Jan 2009 09:05:41 +0000 Subject: [Opendnssec-develop] face2face agenda: design diagrams In-Reply-To: <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> References: <20090127084520.GB32586@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> Message-ID: <20090130090541.GA17076@phantom.vanrein.org> Hello Rickard, There are a few more agenda items that I would like to propose for Monday. * Tasks, priorities, scheduling I would like to discuss what tasks pop up, where they come from, which component is in charge of scheduling. I think this will be a major source of complexity if we want to deliver a reliable signer. One of the possible problems that could arise is that there are many sources of events, and nobody has an overview of what should be done when. Let alone that it would be possible to schedule downtime for maintenance. (Matthijs pointed out this issue.) All these issues make me think that we need some form of realtime scheduler, so we don't have to invent too many wheels. * Robustness through redundancy For some applications, such as TLDs and the root zone, we should look into what it takes to create a robust setup. We do not want to fail our most important domains "just" because of a local earthquake. Designing this into the system is not very difficult, using existing clustering techniques, but it is good to have in mind early in the design process. This can probably be established in the KASP with either of the following approaches: a) The KASP is redundant, for example because it uses a distributed redundancy mechanism (think of MySQL replication, DRBD, ...) and the result is that keys are available to all signers. Slaves can simply be directed to the signer that is currently to be trusted. b) The DNSKEY records of each of two (or more) independent signers are brought into all the signers, in some way that integrates with the IXFR approach and/or with the master name server. Thanks, -Rick From rickard.bondesson at iis.se Fri Jan 30 10:16:02 2009 From: rickard.bondesson at iis.se (Rickard Bondesson) Date: Fri, 30 Jan 2009 11:16:02 +0100 Subject: [Opendnssec-develop] face2face agenda: design diagrams In-Reply-To: <20090130090541.GA17076@phantom.vanrein.org> References: <20090127084520.GB32586@phantom.vanrein.org> <69830D4127201D4EBD146B904119971880B531@EXCHANGE.office.nic.se> <20090130090541.GA17076@phantom.vanrein.org> Message-ID: <69830D4127201D4EBD146B904119971880B758@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > There are a few more agenda items that I would like to > propose for Monday. Thanks Items are noted to the agenda. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSYLTYuCjgaNTdVjaAQg5hwf/YnA6nqAOYpE4twANgfUutbSOOJ1/y63D Ev2xjcHyUv/gQiNPjaP0Ou6oHPuwUQnjbkGxJnglpAeKLN4hBfrRmJS5ozxt6Ope GDjRYXaAEG8dmCW/1kM87PemaUeseep/Q9p+1xr3BFOYKsTVqsL6sU0FtMawQpzf 1FlzUqGzVydqy8mH2OcvAKQW3ZF8fpfG6Z1mBnHSyZr6Pa2e7PZC6vTzgp53J88/ ZVQhlPyYlvd28QUqOrdh+wT7EYr+9Mv+EkDRjDDGluSMNU2XDBdIQjdD+8K0uY/4 WiteLbNZ1T8HII9EVyc3qRXZ3hMi1gvpBx5qU7lu2pnFEtTJ9Q9MOA== =CFYW -----END PGP SIGNATURE----- From jelte at NLnetLabs.nl Fri Jan 30 12:49:41 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 30 Jan 2009 13:49:41 +0100 Subject: [Opendnssec-develop] engine proof-of-concept Message-ID: <4982F765.4060108@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Author: jelte > Date: 2009-01-30 13:46:34 +0100 (Fri, 30 Jan 2009) > New Revision: 120 > > Log: > proof-of-proof-of-concept-concept for a signing engine, see README from the README: what i just committed is a very crude, quickly hacked-together proof-of-concept of the proof-of-concept i had in mind; a python-based 'engine' that keeps track of signing intervals and resigns the zones. it does not do kasp interaction, nor pkcs11, or even configuration loading at the moment, every setting must be set trough the command channel (either 'telnet localhost 47806' or engine_cli.py) there is not much in the form of error checking, the thread locking needs work, and if something goes wrong, it will mangle the signed zone files. It will also fail horribly when too many zones are configured, because it will run out of file descriptors when it does its process pipe magic. It might very well not work at all ;) to run it you must have a compiled version of ldns trunk in your LD_LIBRARY_PATH (DY_LD_LIBRARY_PATH on OSX), and (re)compiled the trunk version of the signer tools. Paths it uses are relative, so the engine will only work if it is run from its own directory. to create the test zones you'll also need the ldns tools in your PATH To create a test setup: cd /signer_engine/test ./create.pl This creates an some test zones and an init script that can be run through the cli to set up those zones with a resign interval of 60 seconds. To run the engine: cd /signer_engine ./engine.py To add the test zones you just created: cd /signer_engine cat test/init_script | ./engine_cli.py If you stop it, restart it, and run the init_script through the cli again, it should recognize which zones need resigning based upon their modified time. Let me know if it works, and what you think. If people like this direction, I can expand on the concept and make something that might actually be usable. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmC92UACgkQ4nZCKsdOncXVowCg1PWE8CemZ0XYGmoeP9m32RXE bWEAoMkAUi1xYykXYgOAIIOCtS/opxT1 =pZUv -----END PGP SIGNATURE----- From jakob at kirei.se Fri Jan 30 16:22:27 2009 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 30 Jan 2009 17:22:27 +0100 Subject: [Opendnssec-develop] anonsvn available Message-ID: <052CFBBB-A571-4E81-A50C-B3770BDDDC6F@kirei.se> anonymous svn access is now available via http://svn.opendnssec.se/. if we want to keep parts of the repo private, please tell me asap and I'll limit access. have a nice weekend! jakob