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@xxxxxxxx> wrote:
>Plan A: few consumers will use DNSSEC between their PCs and the ISP'sSomething else occurs to me:
>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.
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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf