Bill Manning wrote:
thats -one- reason that DNSSEC has gestated these long months/years.
operational feedback killed the first three attempts and may cripple the
current version beyond repair.
Remember that the current DNSSEC protocol was, without much
discussion, chosen without running code, against a counter
proposal of mine with running code.
With the counter proposal, a lot of pitfalls not avoided by
DNSSEC was pointed out. There are a lot of subtlety in DNS
related to delegation, CNAME, wild cards and so on, none of
which was addressed by DNSSEC.
However, the pitfalls are ignored. Resulting implementations
were buggy, of course. The pitfalls are reconsidered and worked
around later only from operational experiences, which was a long
and painful experience.
With the demonstration of so miserable quality of the
specification and implementations, it is not surprising that
DNSSEC is not accepted at all by operators community.
But, I'm not saying running code is above all.
What's essential is not running code itself but acceptance
by the end users, imprecise proxy of which is acceptance by
operators, imprecise proxy of which is acceptance by
implementors, that is, running code, imprecise proxy of which
is IETF consensus, which means there is little point for IETF
to standardize protocols.
Masataka Ohta
PS
It turns out that both the WG and I was wrong that DNSSEC is
not at all deployed is a good thing, because DNSSEC gives no
better security than so called weak security (If you can
trust CAs and their employees between you and your peer that
they won't sign forged public key of you unconsciously nor
maliciously, you can trust ISPs and their employees between
you and your peer that they won't route your packets to
someone else not having the destination IP addresses
unconsciously nor maliciously).
So, instead of introducing DNSSEC, just rely on ISPs and the
destination IP addresses and use 3 way handshakes with cookies
to securely confirm the source IP addresses are not forged.
ISPs are as reliable as CAs. If you think ISPs are not so
reliable, CAs neither.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf