This is a discussion on SO vs DNSSEC - DNS ; This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15-298683662 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Colleagues, Let us suppose that the Signature Only proposal would end up on standards track, what would that mean for DNSSEC? I ...
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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
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.
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
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
-----END PGP SIGNATURE-----
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.