Masataka Ohta wrote:
Ignore DNSSEC.
Technically, it is poorly designed unnecessarily causing a lot of
technical problems such as large message sizes.
But, the most serious defect of DNSSEC, or PKI in general, is that,
despite a lot of hypes, it is not cryptographically secure.
Social attacks on trusted third parties makes the parties
untrustworthy, which means PKI is merely socially or weakly
secure.
DNS has always contained highly dynamic, quickly or already outdated
and non-negligable amounts of incorrect information.
But the inaccuracies used to be primarily of the out-dated and
accidentally wrong kind, not of the maliciously inaccurate ("fake")
kind.
When DNSsec is used, the data in DNS will continue to be loosely
inaccurate or outdated. But inserting maliciously inaccurate ("fake")
data will hopefully become more difficult.
Personally, I firmly believe that any assumption that data in the DNS
could be trusted, is fatally flawed. And that any security architecture
that relies on DNS data being accurate, is fatally broken.
What DNSsec will provide is what is described in rfc-4033 section 3.1
data origin authentication and data integrity protection.
You can get some level of assurance that the successful result from
DNSsec name resolution will provide you an answer from the
entity that has been authorized to administrate a particular zone
and that this data was not modified in transit (network communication)
or at rest (on the nameserver or in caches).
One should *NOT* make any assumptions about the accuracy of that
information in any kind or form. The information could be
outdated, it could be inaccurate and it could have been
created by subverting the administrative procedures of
the registry -- or e.g. by hacking the database which sources
the nameserver's DNSsec zones.
In order to obtain any level of "trust", you would not only have
to configure the keys for specific zones that you trust,
but also create an out-of-band trust relationship
(person-to-person, audit) of the registry administrating the
relevant DNS-zones you want to trust, their equiment and
adminstrative procedures,
*PLUS*
you will need to create an out-of-band trust relationship to
the adminstrator(s) who operate(s) the server(s)/service(s)
for which you want to resolve the names through DNSsec and
their network admins and the operational procedures that they use.
That might be a time-consuming, expensive and error-prone effort
that by itself get outdated, and it scales nowhere considering
the size of the DNS.
At home I'm using ADSL (~3500/500 KBps), get an IP-Address
dynamically assigned by my ISP whenever my DSL-router reconnects.
I'm using it with a flatrate and VoiP, so it's online 24h, but
the connection is dropped at least once per day -- and I *ALWAYS*
get a new IP assigned on re-connect!
I have set up my DSL router to register the IP assigned by the ISP
with dyndns.org (builtin feature of the DSL-router). But whenever
the connection is dropped, that DNS entry with dyndns.org is
inaccurate until my router re-connects and updates it with the new IP.
Anyone who thinks that information in the DNS could be trusted
is either using a funny definition of trust or has no clue how
DNS is actually used and what kind of data it contains (and
how that data is created and maintained).
There are a few things currently being done that will potentially
no longer work when DNSsec is used. Currently, some countries seem
to ask ISP for blackholing or "redirecting" (=faking) DNS-requests for
particular sites. Blackholing in the form of NXDOMAIN may not longer
work, Blackholing by dropping the request may result in clients
walking the list of authoritative Nameservers instead of contining
to pull the ISPs nameserver, and faking will also no longer work
as soon as the relevant zone has DNSsec enabled and the ISP has
no adminstrative control over that zone (the most common case).
Not having read all of the relevant RFCs, I don't know what the
situation will be for companies running with their own DNS universe,
private IPv4 address spaces (10.x.x.x, 192.168.x.x) and potentially
non-official TLD (company.corp). It probably depends whether
and how these companies have made real-world DNS information
available on their internal networks.
DHCP and DNS dynamic update also appears to create interesting
challenges for the use of DNSsec for involved DNS zones.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf