> David Conrad wrote:
>
> > So far, I have seen what appears to be a lot of FUD from Masataka and
> > the usual concerns/complaints about DNSSEC from folks who haven't
> > implemented it in their products or services.
>
> Unlike me, you have no implementation expertise.
>
> I did implement server code for my proposal of "Simple Secure
> DNS" more than 10 years ago to confirm that, unlike DNSSEC, it can
> be implemented easily. From the beginning, I knew it is essentially
> (except to support read/write new RR types from/to zone file) less
> than 100 lines of modification to BIND and it actually was so.
>
> As a lazy implementor, I can design protocols to avoid useless
> implementation efforts. As a faithful protocol designer, I
> implement my design to confirm it actually require little
> implementation efforts.
>
> At that time, because of fundamental complexity, there was no DNSSEC
> implementation.
>
> Thus, I am the implementer who can authoritatively declare that all
> the impelementors and system administrators of DNSSEC do not
> understand both of DNS and PKI and are brain dead.
>
> I, of course, won't bother to implement proven-to-be-fundamentally-
> broken DNSSEC nor join proven-to-be-useless attempts to improve
> the proven-to-be-fundamentally-broken protocol.
>
> Anyway, the other problem of DNSSEC is that PKI, as a concept, is
> fundamentally broken, against which no PKI protocol can be useful.
>
> Masataka Ohta
The current DNSSEC essentially matches "Simple Secure DNS".
NSEC + RRSIG(NSEC) <=> ZL
RSIG(type) <=> RRD + NSIG
DNSKEY <=> ZA
RRSIG(DS) <=> ZSIG
DS <=> RDD(ZA)
The trust model is the same as "Simple Secure DNS".
The threat model is the same as "Simple Secure DNS".
ZL has the same issues as NSEC has.
KSK/ZSK maps directly into this from "Simple Secure DNS".
A secure zone is a zone whose
authentication is provided by the protocol whereas a secure node is a
node authoritatively belongs to a secure zone. A secure zone has its
own secret information to generate signatures for secure nodes in the
zone.
DNSKEY uses public keys which you recommended.
The signature can be verified by
sharing secret information between related parties or by using
private/public key technology.
RRSIG = TYPE + 32768 would have been better than how we
actually did it in RFC 4035.
While things are encoded slightly differently RFC 4035 is
a implementation of "Simple Secure DNS".
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
