The point raised by John Levine is amongst my concerns.
And one of the reasons that I have been looking at a different approach to
the use of DNSSEC information that does not change the DNS model as
radically as the end to end DNSSEC model.
The idea of using DNS resolver as a proxy is a good one in my view. The
problem with that model comes from the broken idea that a mobile host should
accept any DNS service offered via DHCP.
A DNS resolver is a trusted service, a host should not take just any DNS
resolver, it should choose a resolver and establish a secure connection to
it that at a minimum provides authentication but should ideally provide
confidentiality as well.
This is the case irregardless of whether DNSSEC is deployed or not. A DNS
resolver is a trusted intermediary even in the case that DNSSEC deployment
at servers is ubiquitous and clients are capable of DNSSEC end-to-end.
Once we have a model in which the DNS resolver relationship is trusted and
the communication to that resolver is secured, it is possible to use the DNS
resolver in much more interesting ways.
An end host can no more make sense of DNSSEC information on its own than a
single mail server can deal with spam effectively. A DNS resolver with
substantial throughput can collect the state data necessary to apply DNS
information intelligently.
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
I do not want to connect my machines to every domain in the ICANN DNS
repository. And I certainly don't want ICANN to start restricting issue of
domains to people I or anyone else approves.
DNSSEC can tell my resolver what the authoritative DNS registry is. But that
resolver will then edit that registry to remove the domains that do not meet
my security criteria.
On Fri, Sep 24, 2010 at 8:16 PM, John Levine <johnl(_at_)iecc(_dot_)com> wrote:
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
Plan B: consumers will observe that malicious impersonation of far away
DNS servers is rare and exotic, but malware spam arrives hourly, so they
will make a rational tradeoff, take their ISP's advice, and turn off
DNSSEC.
Something else occurs to me:
Plan C: Sophisticated ISPs might configure their own DNSSEC key into
customer resolvers, and sign replacement records with that.
The threat model for DNSSEC has always been, approximately, that the
authoritative server at the far end is friendly, and the middleboxes
are hostile. But we have real situtations where the opposite is true,
quite possibly more often than the other way around.
If we want people deploying DNSSEC widely, we need to make sure it
handles the actual threats they face.
R's,
John
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf