Colleagues,Let us suppose that the Signature Only proposal would end up on standards track, what would that mean for DNSSEC?
I think that Mike's and Bert's arguments that SO is less complex and easier to deploy than DNSSEC bis, are valid to some extend. SO carries DNSSEC label at less expense than DNSSEC-bis (that is a marketing thing). So those that will start to look to DNSSEC at the moment SO is available will do a minimal implementation or only deploy SO zones. Essentially DNSSEC compliance will probably boil down to MUST implement SO and MAY implement DNSSEC-BIS. My crystal ball functions well enough to predict that DNSSEC-bis will not be implemented/deployed to an extend to achieve useful interoperability. Once SO is standardized then DNSSEC-bis will, effectively, be dead.
Personally I try to be open to new ideas and occasionally reread the "Emperors clothes" just to remind me of the healthy mindset. Nevertheless, RFC3833 was our requirements document, it is only 2 years old, and I find it difficult to believe we have worked on all the PNE issues without believing in them.
Mentioning "2 years" reminds me of the "15 years argument". While it is true that DNSSEC was first thought of 15 years ago, I do not think it is fair to compare it to the time DNSSEC had to catch up on deployment. RF4033-4035 have been finalized by this group less than 2 years ago. For TLDs DNSSEC deployment is something that takes a wee bit of planning and thinking. I do think that the root and the TLDs are important first players. If they play others may play as well.
We, as a working group, have given a number of signals that DNSSEC- bis is fixed and that those who do not care about zone enumeration can start signing their zones today. Some organizations have actually tried to break through the chicken-and-egg problem by investing in software, infrastructure and documentation. Effectively they only started about 2 years ago. In my simple view the SO copes with the lack of deployment by cutting away some of the complexities and turns the whole DNSSEC thing into lower-hanging fruit. Are we sure that lower hanging fruits taste better in the end? Will those low hanging fruits be sold? Why did we invest in growing the tree in the first place?
I remember that in 2001, or thereabouts, I had a chat with somebody who argued that DNSSEC according to rfc2535 should not be changed because the complexities in the key exchange between child and parent could be automated. I am happy I did not fully buy-in to his statement and that we ended up with DS (as if my buy-in made a difference :-)). I do remember a part of his chain of arguments. To paraphrase: If you can automate the complexity then only the implementor needs to deal with it. But the argument probably does hold for PNE; all PNE complexity disappears in the software (and I think one may expect some expert trouble shooting tools).
Anyway, this all boils down to the blunt question: Should we flush all DNSSEC-bis work and put our bet on SO?
Flushing DNSSEC-bis would mean re-charter of the group. I think that would only be prudent for such a drastic change of direction.
--Olaf namedropper (no hats)PS. I can think of fall-back scenarios with ENUM where authenticated denial will help you when deciding if your asterisk server falls back to a PSTN call, gives a busy tone, or provides a voice message "Sorry you are not allowed to call over-seas".
----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/
Attachment:
PGP.sig
Description: This is a digitally signed message part