Mark Andrews wrote:
> The current DNSSEC essentially matches "Simple Secure DNS".
Well, mostly. Thank you for your pointer to RFC4035 I ignored.
And, congratulations that the WG has wasted only 10 years of
implementation and operational experiences to reach the
conclusion that the original DNSSEC is, as I said with a small
implementation and no operational effort, broken.
Now, I'm saying, for these 10 years, that PKI, including DNSSEC,
is broken.
Can't you simply believe me?
> NSEC + RRSIG(NSEC) <=> ZL
> RSIG(type) <=> RRD + NSIG
> DNSKEY <=> ZA
> RRSIG(DS) <=> ZSIG
> DS <=> RDD(ZA)
> RRSIG = TYPE + 32768 would have been better than how we
> actually did it in RFC 4035.
Yes, An essential difference is that NSIG is a lot more compact than
entire RSIG or RRSIG.
However, another essential difference is that as you increases the
variations of cryptography algorithms, the size of the entire RSIG
or RRSIG increases, which is, IMO, more serious than the increase
of possible RR types.
So, I designed simple secure DNS so that everything fits within
512B assuming RSA data of 1024 bit or 1500B assuming 2048 bit
(Unlike many Japanese, I don't believe in PK with elliptic
functions).
> ZL has the same issues as NSEC has.
The non-issue is based on a misunderstanding that online generation
of signature were insecure, even though the signature generation
mechanism must, anyway, be socially accessible.
That signature generation mechanism is accessible on line dose not
necessarily mean that a private key is accessible on line.
> KSK/ZSK maps directly into this from "Simple Secure DNS".
I have no idea on what KSK/ZSK means. But, it's OK.
> DNSKEY uses public keys which you recommended.
As a person who dose understand PKI but without much expertise on it,
I was not sure that public key cryptography was reliable. So, I tried
to make "Simple Secure DNS" work with shared key cryptography with
KDCs.
Now, I'm sure neither CAs nor KDCs are not very reliable, because
they need blind belief on intelligent intermediate entities of CAs
or KDCs, directly violating the end-to-end principle.
Masataka Ohta
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
