> Dean Anderson wrote:
>
> >>1) What is more broken with DNSSEC then on DNS?
>
> DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives
> users false sense of security.
>
> > The question really should be 'What is LESS broken with DNSSEC than with
> > DNS?' Equally broken is bad, too. 'More broken' is clearly a disaster.
> > 'Not broken' is the goal.
>
> I was enlightened on two things through designing and improving simple
> secure DNS, which is a PKI-based cryptographically secure DNS consistent
> with PODS. They are:
>
> 1) precise authority model of referral and glue A, which is why
> I know how to fix cache contamination through glue A
>
> 2) Meaninglessness of DNSSEC, or PKI in general, with no better
> security than PODS
>
> Just like the Internet is a network of ISPs and end users, a PKI is a
> network of CAs and end users. If you can blindly believe in that CAs
> and end users are secure, you can blindly believe in that ISPs and end
> users are secure, both of which are, of course, wrong. However, with PKI
> the former is silently assumed and PKI is claimed to be cryptographically
> secure, which is the fallacy of PKI.
>
> For example, even if you make your signature generation mechanism not
> accessible online through the Internet, the mechanism must be, to keep
> the PKI work, accessible through the network of CAs and end users,
> which means the mechanism is effectively online, where "effectively"
> means attacking is equally easy.
You already have to trust your parents to publish your
delegating NS RRset. If they don't then you are in trouble.
DNSSEC does not change that pre-existing trust relationship
which is required for DNS to work.
Unless you control all aspects of the communication you end
up having to trust someone. The question is who do you
trust and is that appropriate for the thing that is being
secured.
The DNSSEC trust model is in parallel to the trust model
of the thing it is securing (DNS).
> That is, WG discussion on securing NXDOMAIN has been totally
> meaningless.
That really depends on which persons you are attempting to
prevent tampering from.
> For another example, just as a packet with 16 bit ID and 32 bit source
> address should not be blindly believed, a person with an ID badge with
> 16 digit ID and issuer's name of your parent CA should not be
> blindly believed, though both of them are blindly believed so often.
>
> To break DNSSEC, a phishing site pretending as your parent CA and
> requesting you enter your private key is often enough.
Which like most things to do with security is a matter of
education.
> >>2) If DNSSEC is flawed, where is a better alternative?
>
> > I think there are indeed better alternatives.
>
> As I already posted, try to improve implementations to use TCP with
> random sequence number and random port, which is not more
> difficult than to improve caching behavior of implementations.
TCP only addresses one of the issues.
> Masataka Ohta
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
