Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 01:03 AM, Suzanne Woolf wrote: On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Although we have already better understanding for guidelines that are more complete and have improved clarity. So perhaps These are the guidelines as best we understood them ;). But perhaps B is the best option, although minor surgery is still needed before publishing. That includes text like Andrew suggested. Then this document can serve as input for -bis documents. Best regards, Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMvqk0AAoJEA8yVCPsQCW5pVUH/3xKquLmz1ZPADjKOPx6k4Ad dnLA8j+NCeC+jJjQiNybDQ9fWy0soHuEFvZttsRlZkDeb/ClXhkgB3awGz0mDSNo VfKCT24aZIwHzvZ3T+II0d73NAnFBD/AdeHRE9DBp5HFxzGz23FpJBwfXUP5StFt 9DGpc1ZSE2krv8J6TjfjkZW1OImZaxuvldilnXNzn2qTb1uytziim9nMkVinAN9n tanb6S7S5Z5ihAb1tFLL8xT1Co3B49OBDoT36y29J0OOsPQogJ8naPmlsmK0Iq8h a0g4F3nzPl4kIo45Kqwga1GFdvPbTaOXwubvFqIYVDMIc3hflisHH5V/xtTiILM= =3+ns -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On 20/10/2010 4:32 AM, Matthijs Mekking wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 01:03 AM, Suzanne Woolf wrote: On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Although we have already better understanding for guidelines that are more complete and have improved clarity. So perhaps These are the guidelines as best we understood them ;). But perhaps B is the best option, although minor surgery is still needed before publishing. That includes text like Andrew suggested. Then this document can serve as input for -bis documents. Best regards, Matthijs I agree that at this time option B is the best one. I will send editors nits from my review of the document. The disclaimer should be that this document covers only rolling keys of the same algorithm, it does not cover transition to/from/addition/deletion of different algorithm. I would also recommend that this document be published as informational. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
All, This document has been making the rounds for some 2.5 years now, initally as a personal submission by the authors, and later on as a WG document. The reason that it has taken so long is a combination of * the subject matter being quite complicated and several re-starts trying to find the best approach for description * the need to track an evolving subject matter, interact with other documents like 4641-bis, etc * the usual sundry time constraint issues for authors, editors and reviewers The present state is that we have a document that's fairly stable, has been reviewed several times with nits fixed in between. So it is almost ready to go, isn't it? Well, not necessarily... One of the problems with delays is that over time you gain a clearer understanding of what was once new. Another is that when that perfect 20/20 hindsight appears you realise that if you were to start over you would do it in a different way. And this is perhaps where we are now. There are significant changes that are being discussed, including: * a section on rollovers of the so-called CSK (Combined Signing Key) in addition to the treatment of KSK and ZSK rollovers. * there is a lack of clarity in the current definition of key states that would benefit from further work. For instance, current logic assumes that a transition from one active key to the next is immediate, while for large zones it is becoming clear that signing with the new key may be a gradual phase-in that will take some time until all signatures are replaced. See the recent email from Matthijs Mekking. * alternatively, a more fundamental change would be to completely change the terminology by switching away from a state description that is key centric (i.e. keys have states and the rollover progresses as a function of the keys changing states) to instead be rollover centric (i.e. the rollover has states, and keys change behaviour and tasks as a function of of the rollover changing states). However, it would allow for a consistent terminology across all types of rollovers. * manage the complexity and problems finding reviewers by splitting the material into two documents, the first laying down terminology and defining states and transitions, the second having all the math, equations, and complete treatment of all consequences of all choices of rollover mechanisms. The first document would be of more general interest and the latter clearly more of relevance to implementers. However, doing major surgery like this at this time would clearly delay publication significantly and we are therefore at a point in time where we have to ask the WG for guidance on how to best proceed. We see the following three paths forward: A. Improvements should always be incorporated, even in the light of further delays. This is also known as the This Time For Sure-alternative. B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. C. Drop it. If it isn't sufficiently cooked after getting on for three years, then perhaps it s/after three years/after getting on for three years/ is either a case of bad ingredients, or incompetent chefs. Also known as the This Parrot Is Dead-alternative. We are willing to proceed in either of these directions, and we do have opinions on what to do with this. But, as this email is the problem statement, this is not the place to express them. So there it is. Please speak up on where we ought to go with this. A, B or C (or some other alternative not listed above). Regards, John, Stephen and Johan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
At 10:22 AM -0400 10/19/10, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. +1 to Andrew's addition, and maybe add another one: Some of the techniques and ideas that DNSSEC operators are thinking about that differ from this document include and a list of interesting phrases, no details. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Sorry guys-- I don't think the parrot is dead enough to get you off the hook. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
